Database development
in [Java Programming]
|
Prev: Null pointer issues
Next: Urgent
From: Martin Gregorie on 26 Apr 2010 17:03 On Mon, 26 Apr 2010 20:41:11 +0100, Tom Anderson wrote: > I suspect documents may have more than one keyword, in which case your > query might look like: > I suspect you're right, unless the keywords are pulled out to form a unique list in its own table with a M:M relationship to Document, which be useful in some circumstances. However, I didn't persue that since what I really wanted to illustrate was the benefits of indexing heavily searched non-key columns in the right circumstances and of generating result sets that don't contain irrelevant data. Both seemed to be points that hadn't occurred to the OP judging by his comment about searching out required rows from the result set. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Zlatko Đurić on 26 Apr 2010 17:54 On 04/26/2010 11:03 PM, Martin Gregorie wrote: > On Mon, 26 Apr 2010 20:41:11 +0100, Tom Anderson wrote: > >> I suspect documents may have more than one keyword, in which case your >> query might look like: >> > I suspect you're right, unless the keywords are pulled out to form a > unique list in its own table with a M:M relationship to Document, which > be useful in some circumstances. However, I didn't persue that since what > I really wanted to illustrate was the benefits of indexing heavily > searched non-key columns in the right circumstances and of generating > result sets that don't contain irrelevant data. Both seemed to be points > that hadn't occurred to the OP judging by his comment about searching out > required rows from the result set. > > Hmm. My docs and folders are all "nodes". Stored in the node table. Nodes have metadata - such as authors, keywords, document id's, departments, this and that. Those are stored in the metadata table. Now, to get all the info about one doc, you have to get it's node ID, and the go to the metadata table, and find out the metadata that means "parent node", get it's id, then get this parents' children (to get other documents in this set), then get all those documents and search for some keywords in those documents. -- Zlatko
From: Lew on 26 Apr 2010 18:21 Martin Gregorie wrote: >> I suspect you're right, unless the keywords are pulled out to form a >> unique list in its own table with a M:M relationship to Document, which >> be useful in some circumstances. However, I didn't persue that since what >> I really wanted to illustrate was the benefits of indexing heavily >> searched non-key columns in the right circumstances and of generating >> result sets that don't contain irrelevant data. Both seemed to be points >> that hadn't occurred to the OP judging by his comment about searching out >> required rows from the result set. Zlatko Đurić wrote: > Hmm. My docs and folders are all "nodes". Stored in the node table. > Nodes have metadata - such as authors, keywords, document id's [sic], > departments, this and that. Those are stored in the metadata table. > > Now, to get all the info about one doc, you have to get it's [sic] node ID, > and the go to the metadata table, and find out the metadata that means > "parent node", get it's [sic] id, then get this parents' children (to get > other documents in this set), then get all those documents and search > for some keywords in those documents. You don't have to do it that way. You could do it with a correctly set up query involving JOINs, which is the point Martin and others are making. Think set intersection instead of procedure. -- Lew
From: Zlatko Đurić on 26 Apr 2010 18:49 On 04/27/2010 12:21 AM, Lew wrote: > You don't have to do it that way. You could do it with a correctly set > up query involving JOINs, which is the point Martin and others are making. > I'm not, the application is. > Think set intersection instead of procedure. > I will, thanks. -- Zlatko
From: Arne Vajhøj on 26 Apr 2010 20:17
On 26-04-2010 05:14, Pitch wrote: > In article<3d3dbd92-01d3-4ad7-bb94-3855c7e2b221 > @y6g2000prk.googlegroups.com>, junw2000(a)gmail.com says... >> When I work on database development projects, I use JDBC and SQL. Many >> people use hibernate/spring. Can somebody explain the pros and cons of >> using JDBC and SQL vs using hibernate/spring on database >> developments? > > I always believed that ORM systems are forcing you to write your own > business-rules layer apart from the persistence layer. It is not enforcing anything. Hibernate or any other ORM does not refuse to persist classes with business logic in. There is a certain correlation, because when people start to use ORM then they have also learned about PL-BLL-DAL (let us ignore the fact that they probably should have learned about PL-CL-BLL-DAL). > That way database > access is kept simple and easy mantainable. > > Also, this multi-tier architecture allows for easier load-balancing, > architecture changes, integration with other systems, development.. layers != tiers Arne |