> [...] but... SQL is really ugly. it's > not hard to construct something that provides the same functionality > in a much more palatable form. aesthetics aside, if you're dealing > with a database-heavy app, it can make the code much easier to read.
could you explain what in particular is objectionable about sql? i wrote about 100k lines of sql and pl/sql for a 1tb database in the late ninties. (doesn't sound very big anymore.) i found it easy to develop, read and maintain. it almost felt like cheating. there was about 100k lines of application / web stuff that went along with it. > not any harder but a lot less general is the option of wrapping the > database around a higher-level abstraction. you can do things like > data constraints and validations in the application code, rather than > in the sql database itself, which always feels like this random > bolt-on to the application logic. of course this is a difficult roe to hoe. the database can change table.name from varchar(10) to varchar(32) without consulting the application code, or vice versa. seperating the constraining fact from the constraint seems like a fundamental error to me. alternatively, one can just as easily use stored procedures to validate input. then the validation can work against the live constraints. checks like "the document.id must be a valid document.id" can be done race-free in a stored procedure without doing a dance between the application and db while holding a transaction lock. - erik
