Схема базы данных для больших [закрытых] веб-приложений

Недавно я узнал, что в SaaS есть название для такого рода вещей, когда приложение и база данных совместно используются компаниями:

Multitenancy

Определенно company_id.

Создание новой таблицы для каждого чего угодно, не говоря уже о новая БАЗА ДАННЫХ - была бы абсурдной (и действительно является кормом для многих сообщений Daily WTF).

В этом весь смысл использования реляционной базы данных - вы связываете вещи вместе.

Если вам нужно затем сделать базу данных больше, есть масса способов сделать это (главный / подчиненный, главный / мультислейв, двойной главный, горизонтальное масштабирование, просто покупка тонны ОЗУ и т. д.).

FWIW: у моего последнего приложения было ~ 12 миллионов пользователей (~ 300к на день); у него было две базы данных (горизонтальное масштабирование; сделано предыдущими парнями. Я не согласен с этим решением и просто использовал бы ведомые устройства).

РЕДАКТИРОВАТЬ: Предостережение - это предполагает, что вы открываете доступ только через свой приложение (либо его веб-интерфейс, либо API).

Если вам действительно нужно открыть базу данных напрямую клиентам, а) попросите их подумать еще раз, потому что это плохая идея, и б) тогда вам, возможно, придется сделать трудный выбор между тем, что легче поддерживать, что сохраняет необходимый брандмауэр. Но, честно говоря, вы не хотите туда идти, если можете.

просто покупаю тонну оперативной памяти и т. д.

FWIW: у моего последнего приложения было ~ 12 миллионов пользователей (~ 300 КБ в день); у него было две базы данных (горизонтальное масштабирование; сделано предыдущими парнями. Я не согласен с этим решением и просто использовал бы ведомые устройства).

РЕДАКТИРОВАТЬ: Предостережение - это предполагает, что вы открываете доступ только через свой приложение (либо его веб-интерфейс, либо API).

Если вам действительно нужно открыть базу данных напрямую клиентам, а) попросите их подумать еще раз, потому что это плохая идея, и б) тогда вам, возможно, придется сделать трудный выбор между тем, что легче поддерживать, что сохраняет необходимый брандмауэр. Но, честно говоря, вы не хотите туда идти, если можете.

просто покупаю тонну оперативной памяти и т. д.

FWIW: у моего последнего приложения было ~ 12 миллионов пользователей (~ 300 КБ в день); у него было две базы данных (горизонтальное масштабирование; сделано предыдущими парнями. Я не согласен с этим решением и просто использовал бы ведомые устройства).

РЕДАКТИРОВАТЬ: Предостережение - это предполагает, что вы открываете доступ только через свой приложение (либо его веб-интерфейс, либо API).

Если вам действительно нужно открыть базу данных напрямую клиентам, а) попросите их подумать еще раз, потому что это плохая идея, и б) тогда вам, возможно, придется сделать трудный выбор между тем, что легче поддерживать, что сохраняет необходимый брандмауэр. Но, честно говоря, вы не хотите туда идти, если можете.

Я согласен с этим решением и просто использовал бы ведомые устройства.

РЕДАКТИРОВАТЬ: Предостережение - предполагается, что вы предоставляете доступ только через свое приложение (либо его веб-интерфейс, либо API).

Если вы действительно необходимо предоставить базу данных напрямую клиентам, а) посоветовать им подумать еще раз, потому что это плохая идея, и б) тогда вам, возможно, придется сделать трудный выбор между тем, что легче поддерживать, что сохраняет необходимый брандмауэр. Но, честно говоря, вы не хотите туда идти, если можете.

Я согласен с этим решением и просто использовал бы ведомые устройства.

РЕДАКТИРОВАТЬ: Предостережение - это предполагает, что вы предоставляете доступ только через свое приложение (либо его веб-интерфейс, либо API).

Если вы действительно необходимо предоставить базу данных напрямую клиентам, а) посоветовать им подумать еще раз, потому что это плохая идея, и б) тогда вам, возможно, придется сделать трудный выбор между тем, что легче поддерживать, что сохраняет необходимый брандмауэр. Но, честно говоря, вы не хотите туда идти, если можете.

s проще в обслуживании, что позволяет сохранить необходимый брандмауэр. Но, честно говоря, вы не хотите туда идти, если можете.

s проще в обслуживании, что позволяет сохранить необходимый брандмауэр. Но, честно говоря, вы не хотите туда идти, если можете.

We had exactly this issue a few months ago in a product that is often used by organizations that, in turn, serve multiple clients. They came to us asking us to modify our SaaS system so they could create complete, discrete web sites for each of their clients (we build an online, domain-specific web-site construction tool).

A short summary: it may seem obvious to put everyone on a single database but, as you probe deeper, you'll find it isn't always cut-and-dry. There are a few challenges that you'll want to keep in mind as you proceed. A couple of points:

First, it isn't enough to just add "Company_id" to a few tables. Indeed, despite Sai's comments about it being ridiculous to have a database/app for each company there are absolutely cases where this makes sense due to the underlying complexity of hosting SaaS systems for multiple, discrete clients. If you are simply serving a few different companies (e.g. creating invoices for them) then Sai's comment is quite true. If you are providing a software application to multiple organizations, however, the complexity is quite a bit higher and discrete databases may well be in order.

Second, be prepared for a significantly more complex user querying and reporting effort in a multi-client database. For example, when building our user-querying capabilities we had to be absolutely certain that there would be no "bleed-through" between organizations as there was HIPAA-protected data involved. This meant that the querying and reporting capabilities required a level of engineering far in excess of what had gone before. In our case, our querying capabilities were very flexible and essentially permitted users to construct queries on the fly (subject to some pretty stiff constraints, obviously - we weren't accepting SQL!). Thus, we had to make sure that every query was automatically modified to use the "Company_ID" constraint, as appropriate, no matter what the origin of the data or the permissions of the staff member submitting the query. The wrinkle? Our 'super-user' analysis account had to be able to run the queries without such a constraint...

Third, you probably do not yet anticipate just how many things need to be separated. For example, I had built a quite sophisticated "Settings" object into the site that pulled settings from the database on startup and maintained them in the "Application" object (this is a .NET app). This all needed to be floated to handle multiple organizations.

For another example, fields that used to be unique for us (e.g. logins) now had to be done as part of a Company_ID, LoginID key. If you are building from scratch, this isn't such a big idea, but we were retrofitting so it was.

Anyway, as I proceeded through the build, I was surprised to find out just how much work was required to do this right.

Fourth, I always build software using a "meta-programming" approach. That is, I rarely build a single-purpose page but rather often build a highly customizable framework in order to facilitate end-user customization and internal code reuse. While I anticipated that this would help with a transition to multi-organization databases, it often did not! Because such coding is often fairly complex to begin with, floating the Organization was often more difficult than if I simply had a vanilla web page.

Finally, if there is no crying need to share data (e.g. analysis of overall usage patterns) then you might want to stick with discrete databases simply to facilitate scaling. While you add new multi-org databases (a second discrete system), our scaling often involved existing clients that suddenly experienced a surge in growth. Peeling them out of an existing database and onto a new server is a bit more difficult than just moving to a new server with an existing database.

With all of these caveats, you might think I'd advise you against building a system capable of handling multiple organizations on a single database. However, this isn't the case: there are some real wins taking a multi-org approach! Usage analysis, cross-organizational reporting, application deployment, etc. are all significantly enhanced. I just want to provide you the benefit of our experience in the hopes that it'll help you anticipate some of the difficulties that you may anticipate.

При запуске программного обеспечения как службы всегда есть несколько вещей, которые следует учитывать при выборе стратегии базы данных. Два аргумента в пользу отдельной базы данных для каждого клиента - это резервное копирование и (ощущение) безопасности. Если у вас есть одна база данных с незаметным полем customer_id, а клиент 666 ошибается и хочет восстановить свои вчерашние данные, вам нужно поработать.

Иметь единую базу данных для каждого клиента также иногда требуется этому клиенту, поскольку данные могут быть конфиденциальными. Он мог бы справедливо возразить, что более экономно помещать данные в разные базы данных и устанавливать хорошую безопасность.

-Edoode