On Friday 24 April 2009 21.44:33 mdipierro wrote: > SQLAlchemy focuses exclusively on relational databases and does not > set restrictions on which tables can be accessed. This makes it great > for legacy databases. web2py's DAL instead was designed to force the > developer to follow good practice (as we defined] it): every record > must have a unique auto increment id field and this record must be > used for references.
you asked for it... > This brings up a question I have and I have not had a decent answer > to. Other than for accessing legacy databases why would one need > SQLAlchemy over the web2py DAL? Without having looked into DAL at all: alone from the description above, it makes me instantly dislike it. (If you're starting to foam at the mouth already: jump to the last paragraph and come back here.) I like to control the database. I know SQL, and when I design my database schema, I do it as "desigining a db schema". The model in a web application *may* be a good way to specify it, but ultimately, I want to be in control about what tables get created, what the columns are, how the primary key is built etc. Yes, I understand that being able to make assumptions about stuff like "autoincrement primary key on every table" allows for some beautiful and quite stunning optimisations/automatisms, and being my own master in terms of DB layout makes me pay for it by not having these simplifications available. OTOH with the 'make some assumptions' kinds of frameworks I'm always afraid that these assumptions will bite me at some point where what I want suddenyl doesn't match with what the framework designers think how stuff should be done. Please take this as what it is: pure opinion. Like: When somebody doesn't like Pizza it doesn't mean Pizza is bad, but just that he doesn't like it. cheers -- vbi
signature.asc
Description: This is a digitally signed message part.
