tedd wrote:
At 3:17 PM -0400 9/3/07, brian wrote:
Well, yes, that would work also but is horribly inefficient because
the *entire table* must be altered any time a row is deleted.
"horribly inefficient"?
Renumbering anything is pretty quick these days. To me, things that are
"horribly inefficient" are also slow. So, I don't agree. If I remember
correctly, I can even renumber a 100K item dB auto_increment index in
less than one second -- but I wouldn't recommend it. I think that's
pretty quick.
It may be just fine in your case, but from a DB design standpoint it
most certainly is not efficient. Why re-order the entire table for
something like this? Altering an entire table because one row has been
deleted suggests to me that the schema needs to revisited.
Well, not seperating data and presentation would be another problem,
IMO. What if the client decides that Roman notation is cooler? You
have to ask yourself what this 'counting column' is doing in your
database. Let PHP/Python/XSL/whatever take care of numbering the rows.
No one said that what was in the dB had to be presented in any form, but
I do have clients who have items in their dBs and want to see a record
number as they pursue their records -- it's only natural.
But this column you're suggesting isn't a "record number" in the
ProductId, PLU, serial # sense, though, is it? One would certainly never
select for it, would they? A particular value would be only *very
tenuously* related to its row, and only until the next time some row is
deleted. So why store it in the row at all?
As for maintaining a record number in a dB I don't see any conflict
whatsoever in separating data and presentation. After all, what's in
your dB should be data and not presentation (however -- I have found
exceptions to this in practical situations when dealing with clients --
they like adding <b> tags to their presentation via their CMS).
It's not about confilcting anything and it's not a presentational issue
in the same sense as having HTML markup in some TEXT field. The issue is
that you want to store a column that is completely unnecessary save for
displaying it. It's a value that should be left to whatever mechanism it
is that's doing the displaying.
Presentation is made during presentation, obviously, by using css and
proper html and pulling data from your dB to assemble presentation. If
the client wants Roman notation, it's a simple process to provide that.
So now you want to rewrite your triggers to use Roman notation? I wasn't
aware that MySQL had such terrific Roman numeral math support.
There is no "separating data and presentation" in this issue.
I don't buy that. Doing it that way is attaching unnecessary
presentation-specific baggage to your data. The column is only as
relational as it was the last time it changed. That is, it was pointing
to a completely different record then. This isn't a "separating data and
presentation" issue?
brian
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
