Timeline for Violating SQL principles
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 11, 2014 at 9:58 | comment | added | Usobi |
Ok, thanks. I have decided to make a database per client and add an order index that will be used always with the ORDER BY clause. I see no reason how the information of two clients should ever be merged.
|
|
| Jan 11, 2014 at 9:45 | vote | accept | Usobi | ||
| Jan 11, 2014 at 4:38 | history | edited | FrustratedWithFormsDesigner | CC BY-SA 3.0 |
deleted 54 characters in body
|
| Jan 11, 2014 at 4:36 | comment | added | FrustratedWithFormsDesigner | @Kevin: Those are some very good points. Most multi-tenant applications I've worked on were either able to reside in the same tables, or were installed in physically different databases (so the complete schemas were copied and then customized). | |
| Jan 11, 2014 at 1:07 | comment | added | Kevin | Since you addressed the multi-tenancy issue, separating the tables (either by copying tables per client or as a fully separate database) allows you to have separate clients on separate versions (may be required by contract), prevents locking issues for one client from taking down all clients (seen it happen) etc. The 'problems' you dictate are not inherent with these particular approaches but are realities of serving multiple tenants that for legal / operational / regulatory reasons cannot share the same space | |
| Jan 10, 2014 at 17:32 | history | edited | FrustratedWithFormsDesigner | CC BY-SA 3.0 |
added 515 characters in body
|
| Jan 10, 2014 at 17:24 | history | answered | FrustratedWithFormsDesigner | CC BY-SA 3.0 |