3 ms·

RDBMS are more capable in multiple aspects; may it be speed, may it be functionality. I often see developers doing all kinds of things in the application layer

by cygned 10y ago

RDBMS are more capable in multiple aspects; may it be speed, may it be functionality. I often see developers doing all kinds of things in the application layer; enforcing constraints, manipulating data, even sorting and filtering. It's like some folks are feared of writing SQL or don't trust their database.

fuck_google 10y ago
Ideally RDBMS would be an integrated part of the development environment so that you could refactor your code and your data/schema simultaneously. Unfortunately our IDEs aren't mature enough. Perhaps RDBMSs will gradually evolve into IDEs that combine application logic and data management into a seamless whole.
h1d 10y ago
Maybe they got spoiled by ORM mappers that anything beyond standard CRUD may feel cumbersome to write.
- webmaven 10y ago
  > > I often see developers doing all kinds of things in the application layer; enforcing constraints, manipulating data, even sorting and filtering. It's like some folks are feared of writing SQL or don't trust their database. > Maybe they got spoiled by ORM mappers that anything beyond standard CRUD may feel cumbersome to write. A decent ORM[0] will use the constraints expressed in the application to reflect those as constraints in the DB schema as well. Why the duplication, you ask? For the same reason that many of the same constraints are imposed in the front-end code: Responsiveness. Validation that happens in the front-end avoids a request/response to the server just to give the user feedback that their password isn't long enough. Relationships and constraints expressed in the application can avoid querying the database just to get the same kind of feedback. This duplication may seem useless, pointless, repetitive, and redundant, but not all accesses to the web server will be via a JS-enabled client, for example anyone accessing the application via an API. [0] eg. SQLAlchemy: http://docs.sqlalchemy.org/en/latest/core/constraints.html http://docs.sqlalchemy.org/en/latest/core/constraints.html

by cygned 10y ago

fuck_google 10y ago

Ideally RDBMS would be an integrated part of the development environment so that you could refactor your code and your data/schema simultaneously. Unfortunately our IDEs aren't mature enough. Perhaps RDBMSs will gradually evolve into IDEs that combine application logic and data management into a seamless whole.

h1d 10y ago

Maybe they got spoiled by ORM mappers that anything beyond standard CRUD may feel cumbersome to write.

webmaven 10y ago
> > I often see developers doing all kinds of things in the application layer; enforcing constraints, manipulating data, even sorting and filtering. It's like some folks are feared of writing SQL or don't trust their database. > Maybe they got spoiled by ORM mappers that anything beyond standard CRUD may feel cumbersome to write. A decent ORM[0] will use the constraints expressed in the application to reflect those as constraints in the DB schema as well. Why the duplication, you ask? For the same reason that many of the same constraints are imposed in the front-end code: Responsiveness. Validation that happens in the front-end avoids a request/response to the server just to give the user feedback that their password isn't long enough. Relationships and constraints expressed in the application can avoid querying the database just to get the same kind of feedback. This duplication may seem useless, pointless, repetitive, and redundant, but not all accesses to the web server will be via a JS-enabled client, for example anyone accessing the application via an API. [0] eg. SQLAlchemy: http://docs.sqlalchemy.org/en/latest/core/constraints.html http://docs.sqlalchemy.org/en/latest/core/constraints.html