Мне нужно разработать систему, которая представляет несколько «проектов», по одному на каждого клиента в SQL Server, что-то похожее на StackExchange ... та же модель данных, разные сайты (по одному на клиента). Каждый проект имеет одну и ту же модель данных, но не зависит от всех остальных. Я предпочитаю использовать одну базу данных для хранения всех проектов. Какая ваша рекомендация?
Я бы сделал отдельные базы данных, потому что в противном случае, если каждый клиент использует аналогичную схему, вам придется либо объединять таблицы, либо использовать множество префиксов, либо иметь таблицы ссылок, содержащие информацию, идентифицирующую клиента. Кроме того, будет намного проще управлять резервным копированием / восстановлением данных клиентов, если у них есть собственные БД.
На самом деле нет веской причины не использовать отдельные БД, ИМО.
Одним из недостатков отдельных баз данных является внесение изменений в схему; Если у вас есть пара сотен БД, будьте готовы найти умный способ протолкнуть новые таблицы, хранимые процедуры, индексы для их обновления. Еще одним недостатком является то, что зеркальное отображение становится менее привлекательным для решения аварийного восстановления по мере роста количества баз данных.
Если нет крайней необходимости хранить данные в одном месте, я предлагаю их разделить. Это упростит перемещение данных между серверами (например, если вы хотите разделить их по нескольким серверам баз данных после того, как нагрузка вырастет до такой степени, что станет проблемой, или если клиент захочет заплатить за использование приложения внутри компании), он может сделать резервное копирование и последующее восстановление более удобным (в зависимости или, конечно, от используемых вами методов резервного копирования), а также снижает риск ошибок кода, позволяя клиентам (случайно или посредством преднамеренного взлома) просматривать данные друг друга.
Здесь нет правильного ответа. Маршрут purist-dba будет все в одной БД. Если вы хорошо разбираетесь в дизайне / config / sql, вы будете поражены тем, что можно получить от одного современного сервера стоимостью около 8 тысяч долларов. Дешевый и грязный маршрут веб-масштабирования будет 1: 1 customer: db. Таким образом, если клиент становится намного популярнее других, вы можете разделить его и масштабировать их настройку. Путистский путь веб-разработчика будет состоять из «одной» базы данных, но построен в виде больших таблиц / динамо-машин для широкого масштабирования.
Это действительно становится не столько техническим вопросом, сколько деловым. Сколько у вас сейчас разработчиков и администраторов, насколько они талантливы, что они уже знают, какой трафик вы ожидаете в ближайшем будущем, какой доход потребуется для покупки / аренды оборудования в 10 раз больше, чем требуется для этого и т. д.
В целом, именно поэтому большинство старожилов-стартапов говорят: «Просто работай и сосредоточься».
edit: кроме того, вопрос не может задаваться системным администратором. разработчикам всегда нравится думать о проектах, которые в 10 раз усложняют конфигурацию сервера «на всякий случай».
Я не использую MS SQL, но, как правило, по одной БД на клиента. Гораздо проще иметь дело. К тому же, если одна база данных испортится, а это действительно произойдет, это не повлияет на других ваших клиентов. Любые процедуры обслуживания могут быть написаны для нескольких баз данных так же просто, как для одной.
Я использовал одну базу данных для каждого клиента, и, как уже упоминалось, обновление схемы и резервного копирования abv будет сложным.
Но не так уж и много.
Вам нужно регистрировать всю свою базу данных отдельно (в другой базе данных, по крайней мере, если не на другом компьютере), иметь таблицу с именем schema_update_log или что-то в этом роде и написать сценарий, который обновляет схему для каждой базы данных и регистрирует успех в этом. Итак, если у вас есть 100000 дБ, даже на многих физических серверах вы просто запрашиваете каждый и регистрируете успех, если по какой-либо причине он не работает, попробуйте снова отказавшие базы данных.
Это будет примерно так:
master_databases: (запись каждой базы данных для каждого клиента и ее строка подключения) база данных db_id ...
schema_update_log pk query_id db_id status (pending, success, failed) ошибка отметки времени (на всякий случай)
schema_query query_id (упоминается в schema_update_log) query
затем напишите сценарий для циклического перебора каждого запроса набора данных и обновления журнала, продолжая делать это до тех пор, пока для каждого query_id каждая база данных не вернет успех в schema_update_log.
это займет время, но будет надежнее, чем специальные обновления.
Отдельные БД. В дополнение к другим причинам:
По сути, это намного чище или правильнее: если строки в таблице не имеют ничего общего друг с другом, они не должны находиться в таблице вместе. (Хорошо, я только что придумал это правило.)
Как говорит cagenut, это зависит от обстоятельств. Тем не мение...
Одна база данных на каждого клиента звучит так, как будто в долгосрочной перспективе это может усложнить вам задачу. Что произойдет, если у вас будет 100 000 клиентов? Справится ли SQL-сервер с таким количеством баз данных? Получите ли вы в итоге 100 000 резервных копий базы данных? Как ты с этим справишься? Если это заставит вас больше работать, зачем использовать этот вариант сейчас, если его можно будет изменить позже?
Возможно, сейчас стоит использовать единую базу данных, но подумайте, как бы вы могли разделить данные, если бы у вас было очень много клиентов.
Я бы сказал, что одна база данных для каждого клиента кажется привлекательной для достижения более высокой степени изоляции контента с точки зрения безопасности.
С другой стороны, я думаю, что если вы хотите обслуживать больше клиентов, это будет стоить вам, потому что вам нужно будет предоставить дополнительную инфраструктуру для обработки любых обновлений базы данных, которые, конечно, могут быть выполнены, но кто-то действительно должен сесть и придумайте способ, и в большинстве случаев это делается наполовину вручную. При наличии нескольких заказчиков вы быстрее видите недостатки плохо масштабируемого кода, и это хорошо, потому что вы не переносите его на долгие годы.
это также упростит задачу при переходе от монолитной к микросервисной архитектуре, поскольку вам просто нужно подумать о домене службы, не настраивая дополнительных экземпляров или сред для каждого клиента. Вы всегда должны помнить, что количество разработчиков не ограничено, и чем их больше, тем больше людей вам нужно нанять. Извините за такой экономический ответ, но я думаю, что это необходимо для такого рода вопросов.
Также я хотел бы отметить безопасность, да, но не как единственную вещь, потому что мы также должны стремиться к производительности, которая в конечном итоге также более экологична -> меньше оборудования -> меньше электроэнергии -> энергопотребление. Просто наличие справки для каждого клиента не обойдется вам так дорого, особенно с SQL. Реляционные БД созданы для объединений.