[development] Referential integrity -- finally?
rowan at stasis.org
Wed Jan 24 02:35:50 UTC 2007
On 23-Jan-07, at 12:35 PM, Dries Buytaert wrote:
> When working with databases you want to know _exactly_ what is
> happening with your fields, types, keys and indices -- and the order
> thereof. An abstraction layer makes that less transparant.
But when you're working with Drupal, you're not working with database
fields, tables, etc.. you're working with Nodes, Terms, Vocabularies,
Comments, Users and the like. The fact that these just happen to be
stored in a SQL database is not terribly important to ones line of
thinking when developing most modules.
(If you're really concerned about the specifics of your data at the
database level, you would mandate that the application use stored
procedures for everything. ;)
Requiring that someone be well versed in SQL to do a lot of development
in Drupal is already a barrier to entry. And most people are not expert
DBA's. Just look at the schemas for some of core and contrib :)
> At the same time, an abstraction layer makes it easier to port and
> update modules.
PHP has a crap database API. So (to Adrian's point) the only way to
avoid killing contrib developers and core maintainers with schema
management across X number of databases X-1 of which will most likely
not be their primary SQL dialect is to provide a thin layer for the
parts of SQL that are completely not standardized across
So that for sure includes table creation, and altering, and also
potentially date/time functions if we were to ever consider moving away
from timestamps to leverage good database support for date and time
Module developers are already NOT writing pure SQL to create and alter
their tables.. so we've already thrown up a layer in there that is
ideal for neither developers nor db admins. Why not help developers out
so that they need only write one db_table_create() or db_table_alter()
statement instead of 2 or more?
More information about the development