At 6:18 PM -0400 9/3/07, brian wrote:
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.
From a technical standpoint, I agree with you. It's far better to let
the records fall as they may according to the sort, whatever that may
be.
However, we (or at least I) often work with clients who don't see
that. Instead they see records that they place into their database
that hold information about their widgets and they like to see a
record number associated with their widget. And, when they add a new
widget record, they want to see that count increased and when they
delete a widget record they want to see it gone and a gap, where they
can renumber at their will.
This makes no difference to me, I can do anything they want. But the
point is that customers usually not don't know the finer points to
what "should" or "should-not" be done, but rather they way they think
things should be done. Understand? After all, it's their business --
not ours.
Our charge is to provide them with as much correct information as
they can absorb and then do just what they want beyond that.
Believe me, arguing with clients about how things should be done has
it's limits. At some point, you just have to listen and do what they
want in spite of what is optimal.
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.
I rewrite stuff all the time to make the presentation exactly what
the client expects. Roman numeral math support is really a no brainer
to create -- that's comp 101 sruff.
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?
We are disagreeing if having a record number is necessary or not?
From my perspective, if it is left up to me -- it's unnecessary and
my dB's don't have any. However, if the client wants it, then the
client get's it and it then becomes necessary.
As for relational, I'm not talking about a relational dB field, but
rather a simple record that the client can imagine. Relational fields
are used to present the record, they certainly would not be involved
in any renumbering schemes -- don't you see what I am talking about?
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
