Re: [PHP] Pragmatically changing a "Record Number"

Surely we're into basic database design. If you have an auto_increment
record key that needs changing from time to time then you've designed
the database incorrectly. Use a 'normal' key field such as
"Product_Id" and have your application generate the number.

Simple.

No?

On 9/4/07, tedd <tedd@xxxxxxxxxxxx> wrote:
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




--
Graham
.

Relevant Pages

  • Re: Access Database rights question
    ... win-win" experience for all concerned. ... What my client ... NEW 'export' database with a structure that suits the intended purpose ... In your case I would imagine that the normalised design you are most ...
    (comp.databases.ms-access)
  • Re: Writing a DAL with TDD
    ... I thought that maybe I was missing something about TDD if I was ... idea of applying TDD to designing a database, IMHO, is dangerous to ... a good idea to design a relational database based exclusively or even ... client applications. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Access Database rights question
    ... is a common scenario. ... What my client ... NEW 'export' database with a structure that suits the intended purpose ... In your case I would imagine that the normalised design you are most ...
    (comp.databases.ms-access)
  • RE: Client / Server Design for Windows.System.Forms
    ... Winforms client -> Database ... "Dave" wrote: ... The design of the database can be changed, ...
    (microsoft.public.dotnet.framework)
  • Re: Opinions needed about the best "Middleware suite" kbmMW vs. RODA
    ... kbmMW supports cross db in such way that all you need to do in your application is to set one property to switch to ... What one have to concentrate about is minimizing the amount of data moved from the app server to the client. ... C/S setup's usually have a quite active chatter going on between the client and the database, ...
    (borland.public.delphi.thirdpartytools.general)