6 ms·

What's the distinction between a database access layer and read/write apis? Is that a semantic distinction or do they accomplish different things?

by cirgue 8y ago

geggam 8y ago
from my understanding you get the ability to put the DAL into a "pause" mode where it queues all the api requests allowing you do to updates / upgrades to the database with no downtime. It also gives you a way of controlling what queries are used by the API servers preventing a developer from doing silly things and creating a production outage
- gnahckire 8y ago
  It also makes changing your DB a lot easier since APIs using the DAL don't need to be updated since they're DB agnostic -- you "only" need to update the DAL API.
  - pc86 8y ago
    How often does one change the DB backing a live production application?
    - Lunatic666 8y ago
      I also don't think it's a good idea. If you don't use the database specific functions out of fear you aren't able to switch anymore, you are probably wasting a lot of potential performance.
      - blattimwind 8y ago
        I think "changing the DB" likely referred to schema changes, not swapping out the DBMS.
        pc86 8y ago
        > > > > It also makes changing your DB a lot easier since APIs using the DAL don't need to be updated since they're DB agnostic [emphasis mine] I took it as changing the DBMS under the hood.
    - twistedpair 8y ago
      I've done it twice. If you're experiencing significant growth or change in access patterns, you may for example go from Postgres to a KV store. In one of the cases where I had to switch, we swapped from Cassandra to S3 for 100x OpEx savings since C* couldn't scale cost effectively to our needs, so we rolled a database on top of S3 instead that well out performed C* for our use case (e.g. need to export a 3B row CSV in a minute?).
      - sbov 8y ago
        > you may for example go from Postgres to a KV store. If its easy to do this then you are using a tiny fraction of Postgres. If you want it to be easy to switch your database then you need to code to the lowest common denominator. I would rather use my databases to their fullest potential, rather than purposefully handicap myself because I might have to change it in the future.
      - pc86 8y ago
        I'm sure there are rare exceptions but I would imagine if you dug deeply into the business rules around "I need to export a 3,000,000,000 row CSV file" and into what the users are actually trying to accomplish at the end of that workflow, you could find a solution that meets those goals better while also obviating the need to export a 3,000,000,000 row CSV file.
    - GordonS 8y ago
      I've never done it in my 16+ year working life. I used to design systems so this was possible, but eventually realised it just wasn't needed - I was adding more abstraction and complexity for no reason.
  - segmondy 8y ago
    Yeah, but this is more code architecture than system architecture.
    - deleted 8y ago
      [deleted]
  - deleted 8y ago
    [deleted]
- SolarNet 8y ago
  There are easier database-user level solutions to these problems than increasing ops-architecture with yet another layer of indirection. Personally this is why I hate dev-ops culture, no one knows how to use databases properly anymore. > It also gives you a way of controlling what queries are used by the API servers preventing a developer from doing silly things and creating a production outage Also called database roles. Do your DALs have full database admin credentials?! > mode where it queues all the api requests allowing you do to updates / upgrades to the database with no downtime. This is just a bad idea. Better idea: unless you are rewriting your entire schema from scratch, you should be able to use database views, database triggers, extra/duplicated columns and tables as you make schema swaps. Is that a performance burden? Yes, though it is temporary and a lot less of a burden than a whole 'nother layer of indirection. Does this also allow the really nice feature of not stopping your entire system to change schemas? Yes. How about allowing testing new schemas in production piecemeal? Yes.
  - peterwwillis 8y ago
    I think it's due to the trend against hiring DBAs. Nobody wants to put so much work into their databases anymore. I feel like that was half of the NoSQL craze, let's stop thinking about how to use databases because it's a pain. After a while of slowly modifying and lumping more crap on a database, and it becomes a slow PITA that everyone is too afraid to touch, the usual result is to lift everything onto a new DB. DALs make this easier, but I agree that this should in no way be the point of a DAL. The point should just be to simplify & improve access to the database.
    - geggam 8y ago
      Our DBAs loved the DAL. There is a trend today to let developers run all over production doing what they want and it has direct impact on systems. The complexity of the modern stack is ridiculous. You run java containers inside docker containers inside virtual machines and call it optimized.
      - peterwwillis 8y ago

What's the distinction between a database access layer and read/write apis? Is that a semantic distinction or do they accomplish different things?

by cirgue 8y ago

What's the distinction between a database access layer and read/write apis? Is that a semantic distinction or do they accomplish different things?

geggam 8y ago

from my understanding you get the ability to put the DAL into a "pause" mode where it queues all the api requests allowing you do to updates / upgrades to the database with no downtime. It also gives you a way of controlling what queries are used by the API servers preventing a developer from doing silly things and creating a production outage

gnahckire 8y ago
It also makes changing your DB a lot easier since APIs using the DAL don't need to be updated since they're DB agnostic -- you "only" need to update the DAL API.
- pc86 8y ago
  How often does one change the DB backing a live production application?
  - Lunatic666 8y ago
    I also don't think it's a good idea. If you don't use the database specific functions out of fear you aren't able to switch anymore, you are probably wasting a lot of potential performance.
    - blattimwind 8y ago
      I think "changing the DB" likely referred to schema changes, not swapping out the DBMS.
      - pc86 8y ago
        > > > > It also makes changing your DB a lot easier since APIs using the DAL don't need to be updated since they're DB agnostic [emphasis mine] I took it as changing the DBMS under the hood.
  - twistedpair 8y ago
    I've done it twice. If you're experiencing significant growth or change in access patterns, you may for example go from Postgres to a KV store. In one of the cases where I had to switch, we swapped from Cassandra to S3 for 100x OpEx savings since C* couldn't scale cost effectively to our needs, so we rolled a database on top of S3 instead that well out performed C* for our use case (e.g. need to export a 3B row CSV in a minute?).
    - sbov 8y ago
      > you may for example go from Postgres to a KV store. If its easy to do this then you are using a tiny fraction of Postgres. If you want it to be easy to switch your database then you need to code to the lowest common denominator. I would rather use my databases to their fullest potential, rather than purposefully handicap myself because I might have to change it in the future.
    - pc86 8y ago
      I'm sure there are rare exceptions but I would imagine if you dug deeply into the business rules around "I need to export a 3,000,000,000 row CSV file" and into what the users are actually trying to accomplish at the end of that workflow, you could find a solution that meets those goals better while also obviating the need to export a 3,000,000,000 row CSV file.
  - GordonS 8y ago
    I've never done it in my 16+ year working life. I used to design systems so this was possible, but eventually realised it just wasn't needed - I was adding more abstraction and complexity for no reason.
- segmondy 8y ago
  Yeah, but this is more code architecture than system architecture.
  - deleted 8y ago
    [deleted]
- deleted 8y ago
  [deleted]
SolarNet 8y ago
There are easier database-user level solutions to these problems than increasing ops-architecture with yet another layer of indirection. Personally this is why I hate dev-ops culture, no one knows how to use databases properly anymore. > It also gives you a way of controlling what queries are used by the API servers preventing a developer from doing silly things and creating a production outage Also called database roles. Do your DALs have full database admin credentials?! > mode where it queues all the api requests allowing you do to updates / upgrades to the database with no downtime. This is just a bad idea. Better idea: unless you are rewriting your entire schema from scratch, you should be able to use database views, database triggers, extra/duplicated columns and tables as you make schema swaps. Is that a performance burden? Yes, though it is temporary and a lot less of a burden than a whole 'nother layer of indirection. Does this also allow the really nice feature of not stopping your entire system to change schemas? Yes. How about allowing testing new schemas in production piecemeal? Yes.
- peterwwillis 8y ago
  I think it's due to the trend against hiring DBAs. Nobody wants to put so much work into their databases anymore. I feel like that was half of the NoSQL craze, let's stop thinking about how to use databases because it's a pain. After a while of slowly modifying and lumping more crap on a database, and it becomes a slow PITA that everyone is too afraid to touch, the usual result is to lift everything onto a new DB. DALs make this easier, but I agree that this should in no way be the point of a DAL. The point should just be to simplify & improve access to the database.
  - geggam 8y ago
    Our DBAs loved the DAL. There is a trend today to let developers run all over production doing what they want and it has direct impact on systems. The complexity of the modern stack is ridiculous. You run java containers inside docker containers inside virtual machines and call it optimized.
    - peterwwillis 8y ago