But SQL is a discreet language is it not? And further, the SQL code is entirely model and should be considered a part of the model.
Not sure I understand what you mean by SQL being discreet, but I do agree it’s “part” of the model - although I tend to see it as the low level layer - DAL perhaps.
File listings, while a business logic concern, aren’t part of the database section of the model. The data model means all parts of the model be it file system, db or cache. So that example is a bit of a red herring since you can’t write a SQL query to work with file listings.
Agreed. File operations are just another example of a lower level DAL, just as a web service might be considered one as well. The model API would encapsulate/wrap those DAL functions and provide the required business logic, formatting, conversion, calcluations, etc. IMO anyways.
I consider it a supremely stupid idea to impose artificial limitations to a project. One such artificial limitation is to try to force the database system to be compatible with every possible RDMS out there -
Why? In the enterprise or off the shelf software market, supporting multiple RDBMS is a very real demand. Taking care to write generic SQL whilst using a simplified table data gateway class makes the task far easier. I simply re-create the tables in MSSQL and change a config option and voila - the program just went from working with MySQL to MSSQL. Also this decision is usually made at install - it’s very rare someone switches the RDBMS after installation - in fact I have yet to deal with that - it’s always been an install time requirement.
I have not in all my time programming seen a switch of RDMS systems that didn’t also accompany major shifts in languages and technology that would have made any of the preparation your calling for entirely moot.
It does happen, I assure you. When it was announced MySQL had been acquired by Sun then Oracle, there was a lot of buzz and action on switching to MSSQL. Again though, it’s not so much about switching as it is having that option available during initial install. People will turn down your application based on what RDBMS it supports, trust me. If you are dealing with ASP developers who need your solution but are not comfortable with MySQL and trust more in MSSQL - they will request that. Thats a big market to turn a blind eye on.
I have enough headaches in my life dealing with multiple browser agents, looking at all the neat features the newer ones have, then ignoring them entirely because my sites have to work on IE 7 - the lowest common denominator. I refuse to do the same on the server side where I do get to control the technology in use.
Well thats your personal choice I guess. Flexibility and customizability are two of the most important selling points for any software system, IMO.