3 ms·

In Postgres for example there is just so much arcane configuration that needs to be done before you can start writing code. All that extra guff should be an add

by hoodoof 14y ago

In Postgres for example there is just so much arcane configuration that needs to be done before you can start writing code. All that extra guff should be an add on option for "enterprise users". Why not just the database functionality on its own, stripped of all the complex surrounding bits? Have you ever experienced the pain of configuring pg_hba.conf? Or trying to work out the right user access control to your database entities and then keep it all ok when the database setup needs to be changed? Nightmare.

dragonwriter 14y ago
> In Postgres for example there is just so much arcane configuration that needs to be done before you can start writing code. Not really. > All that extra guff should be an add on option for "enterprise users". It may not be right for whatever toy project you are doing, but that doesn't mean that it isn't right for the baseline of a product that does what Postgres is intended to do. > Why not just the database functionality on its own, stripped of all the complex surrounding bits? The things you call "complex surrounding bits" are part of the core functionality of a RDBMS server. > ave you ever experienced the pain of configuring pg_hba.conf? I've made changes to pg_hba.conf, though for simple development against a default install I usually don't have to. I never found it painful. > Or trying to work out the right user access control to your database entities and then keep it all ok when the database setup needs to be changed? Never had any problem with that. If you don't have really complex security needs -- and especially for the kind of development where its sensible to consider application-managed security rather as an alternative to DB managed security -- its straightforward. You can just create a user for the application, and create a database in the cluster owned by that user, and bam, you're done. For more complex cases, sure, its more work, but then the work is inherent in the more complex cases, not a product of the DB features.

by hoodoof 14y ago

dragonwriter 14y ago

> In Postgres for example there is just so much arcane configuration that needs to be done before you can start writing code. Not really. > All that extra guff should be an add on option for "enterprise users". It may not be right for whatever toy project you are doing, but that doesn't mean that it isn't right for the baseline of a product that does what Postgres is intended to do. > Why not just the database functionality on its own, stripped of all the complex surrounding bits? The things you call "complex surrounding bits" are part of the core functionality of a RDBMS server. > ave you ever experienced the pain of configuring pg_hba.conf? I've made changes to pg_hba.conf, though for simple development against a default install I usually don't have to. I never found it painful. > Or trying to work out the right user access control to your database entities and then keep it all ok when the database setup needs to be changed? Never had any problem with that. If you don't have really complex security needs -- and especially for the kind of development where its sensible to consider application-managed security rather as an alternative to DB managed security -- its straightforward. You can just create a user for the application, and create a database in the cluster owned by that user, and bam, you're done. For more complex cases, sure, its more work, but then the work is inherent in the more complex cases, not a product of the DB features.