[TML] Back to the 21st century SQL question.

[Stuart Frew]

> garry.e.ward at worldnet.att.net wrote:
>
> [snip]
>
>> Transactional processing, however, I consider something that should
>> NEVER had gone into the database.
>>
>> Data integrity rules (such as value checking as well as type checking),
>> can often be better served at the client rather than the server unless
>> the data integrity involves referential integrity (can't add a row in
>> table B if field X doesn't match field Y in table A).
>>
>
> Let me start with the blanket statement that I mean no offense to anyone
> when I disagree. I think that the reason that I love Traveller so much
> is because it provokes arguments nearly as strong as those I see in the
> software engineering community.
>
> I disagree on Transactional processing. Having it in the database
> reduces overall code like the try: ... except: blocks in Python or the
> similar construction in Java. I know that it extracts a performance
> penalty but I feel that modern hardware has reduced this cost to the
> point where the tradeoff: slower transactional database vs. faster
> transactionless database is more than paid for by the simplicity of code
> that uses tranactions to insure integrity.
>
> On Data Integrity rules. There is a certain joy that I get from knowing
> absolutely that there is no way to insert a system in hex 9999 when the
> data definition dictates that a sector consists of the area that spans
> from hex 0101 to hex 2440. Yes, this can be insured from the client but
> my experience has me implementing it in both places. My reasons for that
> are simple. Detecting errors on the client side is detecting errors
> early and that can only make your user interface better. Detecting
> errors on the server side guarantees data integrity against access that
> bypasses the client and the UI.
>

Throwing in my two cents, validation should happen at the both the client
and sever level.

You need it at the client level so the user can have an interactive and
rich experience, with out round trips to the server.

You need it at the server level because the server should not trust any of
 its input from anyone.


> Just from my experience, all the attributes I'm mentioning: referential
> integrity, data consistency, transactional processing; don't seem to be
> all that important at the start of the project. In all of the
> applications that I have built in my life I have never run into a
> project that justified the use of an SQL database and wouldn't have
> benefitted greatly from at least two of these during the application
> life cycle.
>
> -- Chris
>
>
> --
>        __o          "All I was doing was trying to get home from work."
>      _`\<,_           -Rosa Parks
> ___(*)/_(*)___________________________________________________________
> Christopher Sean Hilton                    <chris | at | vindaloo.com>
>          pgp key: D0957A2D/f5 30 0a e1 55 76 9b 1f 47 0b 07 e9 75 0e 14
> _______________________________________________
> TML mailing list
> TML at travellercentral.com
> http://lists.travellercentral.com/mailman/listinfo/tml
>