Ryan W. Frenz wrote:
>
> Is it blatantly wrong to think that I can guarantee
> that each object has a unique id? Because I'm definitely assuming
> that (and enforcing it in client code) right now. The system is
> self-contained (i.e. my app is the only entity accessing the
> database).
I'd assumed these id columns were AUTO_INCREMENT, in which case there is
no way to ensure the values are unique across multiple tables without
ugly hackery.
If your program generates the values, that works only so long as you
only run a single instance of the program at a time. Even running two
copies on the same machine by accident can roach your DB. Don't tell me
you've never seen an impatient user double-click a slow-launching
program's icon twice, thinking they didn't do it fast enough the first
time, so they get two instances.
Such a program would violate 1-3 letters in ACID, depending on how you
interpret it.
If you've gone to the effort of preventing a second instance from
running -- not all that hard to do -- now you have another problem which
is that your program is doomed to forever run as a single instance, or
face a major redesign when that requirement comes up.
Programs that never grow beyond their initial requirements are so rare
as to not be worth talking about. If there's even the slightest
possibility that multi-user could become a requirement, it would be
irresponsible to ship the program with this DB design. Changing it
later isn't a mere refactoring, it's a wholesale dump-and-translate
affair. The longer you put off such major changes, the more expensive
they get.
To drag this back on topic for this list, you might look over the SSQLS
v2 design notes in the Wishlist and the URL linked from the first item
in that section to see if you have some design ideas that would make
this sort of thing easier.
