On 20 January 2011 19:20, Dotan Cohen dotanco...@gmail.com wrote:
On Thu, Jan 20, 2011 at 19:21, Richard Quadling rquadl...@gmail.com wrote:
That is terrific, at least the first half. The second half, with the
Venn diagrams, is awkward!
When you get heavily nested data, the adjacent list
Actually, I'm the customer! But assuming that a customer exists, that
implies compensation, and therefore fair bait.
Then that's different altogether. you get to decide what information
is displayed, and what information is 'sensed', and on what platform.
Yes, but before I get to that stage
If you are doing this often, you could leave spaces in the left and right
values so that you could minimize the number of rows that need to be
updated. The article makes every leaf use x and x+1 for left and right which
forces another update to add a child. If instead you used x and x+20 you'd
Yes, and an edge list model may perform better in other respects too:
http://www.artfulsoftware.com/mysqlbook/sampler/mysqled1ch20.html
http://www.artfulsoftware.com/mysqlbook/sampler/mysqled1ch20.html
Thanks. I am currently reading Trees and Hierarchies in SQL for
Smarties by Joe Celko,
On Fri, Jan 21, 2011 at 12:29, Richard Quadling rquadl...@gmail.com wrote:
Changing data in a database is the role of the database engine. It is
much more efficient to have the cost on the insert than it is on the
select.
Agreed. On insert I could even delegate the operation to another
thread
On Fri, Jan 21, 2011 at 4:44 AM, Dotan Cohen dotanco...@gmail.com wrote:
Then I would have to check what values are available when inserting,
and possibly normalise every so often. I'll think about that, and when
I have enough data in the database I'll set up a test system to play
with the
On 20 January 2011 14:32, Dotan Cohen dotanco...@gmail.com wrote:
I am designing an application that make heavy usage of one-to-many
tags for items. That is, each item can have multiple tags, and there
are tens of tags (likely to grow to hundreds). Most operation on the
database are expected
On Thu, Jan 20, 2011 at 17:00, Richard Quadling rquadl...@gmail.com wrote:
I'd have my items table, my tags table and a join table for the two.
My join table is really simple. UniqueID, ItemID, TagID.
Yes, that is the first approach that I mentioned. It looks to be a
good compromise.
I'd
On Thu, Jan 20, 2011 at 18:20, Dotan Cohen dotanco...@gmail.com wrote:
On Thu, Jan 20, 2011 at 17:00, Richard Quadling rquadl...@gmail.com wrote:
I'd have my items table, my tags table and a join table for the two.
My join table is really simple. UniqueID, ItemID, TagID.
Yes, that is the
On 20 January 2011 16:20, Dotan Cohen dotanco...@gmail.com wrote:
On Thu, Jan 20, 2011 at 17:00, Richard Quadling rquadl...@gmail.com wrote:
I'd have my items table, my tags table and a join table for the two.
My join table is really simple. UniqueID, ItemID, TagID.
Yes, that is the first
I cannot agree more with the others about using a join table. While it's
tempting to go with your first solution due to fear of performance issues,
you can usually address performance issues with a technical solution.
Addressing problems that arise from a constraining design choice is much
more
Pseudo = Design Algorithm
Design Algorithm = Actual Code
Actual Code = Alterable db tables
Alterable db tables = manipulated data through the app interface with data
--
The lawyer in me says argue...even if you're wrong. The scientist in
me... says shut up, listen, and then argue. But the lawyer
On Thu, Jan 20, 2011 at 19:21, Richard Quadling rquadl...@gmail.com wrote:
That is terrific, at least the first half. The second half, with the
Venn diagrams, is awkward!
When you get heavily nested data, the adjacent set model (where you
have a parentid for every uniqueid), you very quickly
On Thu, Jan 20, 2011 at 20:50, David Hutto smokefl...@gmail.com wrote:
Pseudo = Design Algorithm
Design Algorithm = Actual Code
Actual Code = Alterable db tables
Alterable db tables = manipulated data through the app interface with data
--
The lawyer in me says argue...even if you're wrong.
Is this a troll? Am I about to be baited?
Baited to deploy what is designed to the consumer's specification?
Surely. From what is wanted to what is needed. Troll on that.
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
--
The lawyer in me says argue...even if you're
On Thu, Jan 20, 2011 at 21:24, David Hutto smokefl...@gmail.com wrote:
Is this a troll? Am I about to be baited?
Baited to deploy what is designed to the consumer's specification?
Surely. From what is wanted to what is needed. Troll on that.
Actually, I'm the customer! But assuming that a
On Thu, Jan 20, 2011 at 2:26 PM, Dotan Cohen dotanco...@gmail.com wrote:
On Thu, Jan 20, 2011 at 21:24, David Hutto smokefl...@gmail.com wrote:
Is this a troll? Am I about to be baited?
Baited to deploy what is designed to the consumer's specification?
Surely. From what is wanted to what is
On Thu, Jan 20, 2011 at 7:00 AM, Richard Quadling rquadl...@gmail.comwrote:
I'd recommend using a nested set approach for the tags
(http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
gives a good explanation on the issues and methodology of nested
sets).
Thanks for the
On Thu, Jan 20, 2011 at 22:05, David Harkness davi...@highgearmedia.com wrote:
Thanks for the link. That article proposes an interesting way to organize
the categories. Have you implemented this in the wild? Clearly the design
would work as it's pretty simple, and I like that it removes the
On Thu, Jan 20, 2011 at 12:21 PM, Dotan Cohen dotanco...@gmail.com wrote:
I understood that. My concern is exactly with adding new nodes. There
is no incrementor (++i) in SQL, so knowingly coding a solution that
will require incrementing two fields in half the database rows seems
My concern is exactly with adding new nodes. There
is no incrementor (++i) in SQL, so knowingly coding a solution that
will require incrementing two fields in half the database rows seems
irresponsible.
Yes, and an edge list model may perform better in other respects too:
21 matches
Mail list logo
