4 ms·

Please just no, do not do this. Even the dumbest most simple system there is will evolve beyond simple CRUD access to tables. The second you put your schema on

Please just no, do not do this. Even the dumbest most simple system there is will evolve beyond simple CRUD access to tables. The second you put your schema on the wire, that schema can now never change. That's just such an insane commitment to make.

tengbretson 5y ago
The application layer is typically just a view that maps the data layer to the expectations of the view layer. If you are set on eliminating the application layer surely you could just implement that view in the data layer using... a view.
joevandyk 5y ago
you can use views or functions to easily make changes to the schema
chousuke 5y ago
the database schema is an API like everything else, and you can solve API evolution problems the same way as you would with a web API, using eg. views, stored procedures and versioning. There's no reason not to expose parts of your database schema directly to users as long as you treat it like you would any other API you provide.
- LukeEF 5y ago
  this is a really interesting way to think about it and something that I've given a fair amount of thought to as we embark on a data mesh journey - how does a domain team serve up a schema like an API, how does it evolve, and how do we think about versions.
  - onefuncman 5y ago
    that's what a Schema Registry is for... protobuf is a little more polished around managing forwards and backwards compatibility than avro but they both work.
  - chousuke 5y ago
    I find that there are very few things related to programming that don't constitute an interface in some way, so it feels natural to me to think about everything in terms of the interface it presents to users, both explicitly in what you can express via whatever language you're using, and implicitly via conditions that can't be enforced but are required for correctness. And when you have an interface, you really ought to put some thought into its design regardless of how "private" it is. An API is an interface used by a program in some way, and any user-exposed database objects definitely qualify under that definition.
iammisc 5y ago
> The second you put your schema on the wire, that schema can now never change. That's just such an insane commitment to make. If you change your schema, you can just write a sql expression to convert between schemas 'at runtime'. Like if you have a table with first name and last name and then you decide you really just need the name on the frontend, just change your SELECT statement to concat the two columns, or vice versa.

tengbretson 5y ago

The application layer is typically just a view that maps the data layer to the expectations of the view layer. If you are set on eliminating the application layer surely you could just implement that view in the data layer using... a view.

joevandyk 5y ago

you can use views or functions to easily make changes to the schema

chousuke 5y ago

the database schema is an API like everything else, and you can solve API evolution problems the same way as you would with a web API, using eg. views, stored procedures and versioning. There's no reason not to expose parts of your database schema directly to users as long as you treat it like you would any other API you provide.

LukeEF 5y ago
this is a really interesting way to think about it and something that I've given a fair amount of thought to as we embark on a data mesh journey - how does a domain team serve up a schema like an API, how does it evolve, and how do we think about versions.
- onefuncman 5y ago
  that's what a Schema Registry is for... protobuf is a little more polished around managing forwards and backwards compatibility than avro but they both work.
- chousuke 5y ago
  I find that there are very few things related to programming that don't constitute an interface in some way, so it feels natural to me to think about everything in terms of the interface it presents to users, both explicitly in what you can express via whatever language you're using, and implicitly via conditions that can't be enforced but are required for correctness. And when you have an interface, you really ought to put some thought into its design regardless of how "private" it is. An API is an interface used by a program in some way, and any user-exposed database objects definitely qualify under that definition.

iammisc 5y ago

> The second you put your schema on the wire, that schema can now never change. That's just such an insane commitment to make. If you change your schema, you can just write a sql expression to convert between schemas 'at runtime'. Like if you have a table with first name and last name and then you decide you really just need the name on the frontend, just change your SELECT statement to concat the two columns, or vice versa.