3 ms·

Even in the case of a database that is only used by a single application, there are plenty of circumstances when it's better to interface with an abstract data

by brentb 18y ago

Even in the case of a database that is only used by a single application, there are plenty of circumstances when it's better to interface with an abstract data model rather than the bare database schema. One reason could be a desire to keep your database (somewhat or totally) normalized, while also being able to make queries against more natural (for the programmer) abstractions. It's rarely the case that all of a given user's information is stored in a single table (and for good reason... read up on normalization (http://en.wikipedia.org/wiki/Database_normalization http://en.wikipedia.org/wiki/Database_normalization) if you're not sure why), but it can sure save a lot of programmer time if your data model acts like it's all in a single table. The case of multiple applications or systems talking to a single database isn't really all that different from a single application talking to a database, unless you only have one database call in your entire application. As soon as you're talking to the database in more than one spot in your code, unless you're careful, you start running into the brittleness/dependency issues described by the author. Even if you're the only one working on a given application, in three months you'll have little chance of remembering every dependency created by every database interaction in your application. Abstracting things with a data model won't fix all of the issues addressed by the author of the article, but it sure does make it easier to address them.

Retric 18y ago
Systems that do this tend to burn a lot of cycles without the coder having any idea what's going on. For simple CRUD system that can be OK, but making abstractions above the database is dangerous from a performance standpoint. Edit: There are a lot of DB tools to help you. Adding views let's you keep normalized schema's while simplifying reading data. Triggers can automate logging etc. I often see people using high level data views that end up giving them less power to manipulate data than the DB has. PS: Why assume the schema is going to suck? Often it does suck, but that should be telling you to change the schema. I mean I know people that can't stand ugly code but they are willing to turn a blind eye to terrible databases.

by brentb 18y ago

Retric 18y ago

Systems that do this tend to burn a lot of cycles without the coder having any idea what's going on. For simple CRUD system that can be OK, but making abstractions above the database is dangerous from a performance standpoint. Edit: There are a lot of DB tools to help you. Adding views let's you keep normalized schema's while simplifying reading data. Triggers can automate logging etc. I often see people using high level data views that end up giving them less power to manipulate data than the DB has. PS: Why assume the schema is going to suck? Often it does suck, but that should be telling you to change the schema. I mean I know people that can't stand ugly code but they are willing to turn a blind eye to terrible databases.