> > ... you're looking for a non-sql compliant SQL database where a lot of
> > the data integrity is actually coded in the application :-)
>
> ~
> First past of your statement I acknowledged, but how is it exactly
> that "lot of the data integrity is actually coded in the application"
> ~
Take dates for example: you'd have to code very carefully to catch all the
different ways dates are represented on this planet. Your application has to
handle this since all the database knows at this point is an absolute time
(i.e. seconds since epoch or something the like) and your app has to convert
every occurrence of a date to this format or the database won't find anything
or even worse store something wrong.
Same goes for numbers: if everything is stored in a byte sequence, how does
the database know you try to compare the number 1 with the character "1"?
Again, your app would have to handle that.
To me, that's moving data integrity into the application.
>
> > That approach strips down on application complexity. My apps don't have
> > to do any post-processing
>
> of the data - I query the records I need and the app merely displays them.
> ~
> Again have you actually tested those assumptions?
Yes, I have, as have many others. Simple example: program a website like, say
Facebook. So you have thousands of users from all over the world. Your website
code handles all the data conversions. Now Apple comes along and sells an
iPhone which silly enough a lot of people like and try to use to access your
website. You now face the problem that you need a second website doing the
same thing as the first website except solely made for touch-screen devices.
You will be forced to rewrite a lot of your code because all the data
conversion is in the code. Even worse, if you'd have to make an iphone or
android app in lieu of the second website, you'd have to recode everything you
did in a different language - i.e. objective C.
If you leave these things to the database, you "simply" write a second client
for a different platform and you don't have to fuzz around to get the
conversions correct because the application receives the data already
converted.
Sure this all depends on what application you need this specialized database
engine for. If it's an application for a very defined environment you can
dictate how data is to be input and train users. If it's an application for
the big wild world you will have problems with users doing stupid things
beyond your control like writing "P.O. Box 1" into the zipcode field where you
expected a 10 digit number. I rather have the database catch those cases and
reject storing the bad input. That saves me a lot of validation code in my
app.
