Add a comment

 

Re: The joy of sets

If you have a system where your data integrity is implicit in the source data, and you trust your source data implicitly, and if your business use case allows you the liberty of having periods in your database when the data integrity is breached (e.g when you disable constraints during batch imports) on the proviso that you re-apply the constraints "by hand", you are duplicating functionality provided in the database product itself. If you can apply this argument to the normal use case of the system -- i.e. you don't need any constraints at all -- then you can argue that a relational database is not suited to your purposes: there are products which will import data faster and easier. I guess the design decision to have the bottom layer in any system diagram to be an RDBMS is often made thinking of the standardised API, and the flexibility this decision will give you. But if you are not using the features of a relational database, then, dare I suggest another form of data store may give you benefits in both performance and programming effort.

Re: The joy of sets


Title
Body
HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).