3 ms·
Never understood why each customer would have their own DB. Must be a nightmare to maintain.
by stef25 3y ago
Never understood why each customer would have their own DB. Must be a nightmare to maintain.
- indeed30 3y agoIt makes enterprise sales easier, since it removes a common objection from security, privacy and compliance teams.
- Cthulhu_ 3y agoWouldn't having separate databases (with separate users (per organization)) make more sense from a security point of view? I have no knowledge of these things, I've never actually worked with more than one database in a mysql instance. edit: I tell a lie, I separated the forums and wordpress databases on a website I run.
- vincnetas 3y agoOne DB server can have multiple DB's. In this case we are talking about single DB (not server) containing multi thousands of tables. And im curious what is the use case for such designs.
- icedchai 3y agoI worked on a system like this. Rolling out migrations would take hours.
- asguy 3y agoDid you not parallelize your migrations?
- icedchai 3y agoWe did, but there was only so much migration load we wanted to place per DB server. Some DBs had 100's of customers.
- jasonjayr 3y agoYes; sometimes they do. Thankfully, our product has customer specific use patterns that we've been able to manage/plan/predict peak load for and what not. Of those 300, a random subset of 20-30 would be 'busy/critical' at any given time, and the others can easily tolerate a delay as migrations + schema changes lock and manipulate things.
- wernercd 3y agoSecurity. You have access to stef25_ tables and I don't. The alternative would be we both have access to the same tables with a permission layer to grant access to row. Both choices have trade offs but if company makes a mistake and I now have access to your rows? Seems easier to control access at the table layer rather than the column layer.
- stef25 3y agoSurely a where user.id = 123 would fix that ?
- wernercd 3y agoOr user group... or active directory group... or admin group. super user. etc. Or... you can just split things by tables. Or even shard by databases where I don't have access to your database and vice versa. doing stuff in the application and leaving everything in one database/schema is an option... but don't think you aren't making trade offs and leaving open possible issues by not taking the more comprehensive option like sharding. And that's just one question to ask. Another is what about upgrading the database and segregating customers. can't do that if everyone is on the same database/schema. What if a customer doesn't want to be updated or upgraded? Much like companies paying for Windows XP support because stuff they have relies on the older version of software? "where user.id = 123" is a simple solution that quickly becomes more complicate to put it mildly.