I don't know about dumb as a rock. Here is a short list of stuff that a dumb rock doesn't do, IMHO.
I want the db to be able to do ETL with any data instrument I have and validate if errors are generated as I am doing it. I demand the jobs engine run a specific job when told to do so, alert me when it is done and if an error happens more about that. For my DW environment, I expect data selection and placement into the proper cube.
The email service to push out messages as sprocs define them to the correct person as well as the correct attachment.
I expect excellent security that interacts with my AD for users that come and go their rights follow the proper channel. I also expect that I can go full-on gearhead and define access to a specific object in the database if that is needed.
As limits for growth are defined they better be followed.
Logs are a necessary evil.
I expect to be able to backup my databases and restore them easily.
The api for the dataengine should be available in at least two layers for access.
I want to tell the db what schemas a user or application is allowed to use.
I expect to be able to write functions() that can do specific transformations as needed.
Output can be is dataset, xml, json, in encrypted or non-encrypted form.
I expect the database to adapt to many language sets and allow joins to other databases that are in different ones.
On Wed, Nov 1, 2017 at 2:21 PM, Bill Anderson billand88@gmail.com wrote:
Mike,
Where's your preference in design with these in mind?<<
My philosophy is that the back end database, whatever it is, should be a dumb as a rock. A database should only be concerned with its internal integrity and no more. Anything else is pretty much geared toward vendor lock-in.
But having noted that, FK constraints are absolutely a part of the data integrity. So yes, use 'em.
Views? Sure, that's basically the only way to communicate. Business rules? Nope, stay away. That's for middleware.
Bill Anderson
On Tue, Oct 31, 2017 at 1:26 PM, < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
At the day gig, they use FK constraints and References in their Oracle database schema. Honestly, I got into that years ago with VFP but then kinda fell off that wagon over the years, preferring to just handle some things in the BizObj of the solution rather than put more rules in the backend database. The idea was that if I changed backend databases, I wouldn't need to rewrite a whole bunch of specific DBMS code.
Where's your preference in design with these in mind?
[excessive quoting removed by server]