Дизайн БД: одна большая БД для всех клиентов или много маленьких БД

Question

Ищете любые предложения или советы или даже лучшие практики.Я разработал онлайн-базу данных, используя php и mysql.Это позволяет компаниям регистрировать жалобы и решения и т. Д. Существует база данных пользователей для входа в систему и база данных CIP для регистрации основных данных.2 компании проводят испытания и тестирование базы данных.На данный момент каждая компания использует отдельные базы данных и отдельные HTML-страницы.Мне интересно, как лучше добавить больше компаний.
У меня есть следующие идеи:

1.Иметь одну большую базу данных для пользователей и одну большую базу данных для cip и использовать идентификатор компании или аналогичный для идентификации отдельных записей компаний в базе данных.

2.Использовать одинаковые html-страницы для каждой компании, но выбрать из базы данных, какую базу данных использовать.Таким образом, каждая компания будет иметь отдельную базу данных CIP, но все компании будут использовать одну и ту же базу данных пользователей.

3.Или просто держите все отдельно для каждой компании.(это может быть очень плохо для обновления)

Надеюсь, я дал понять и буду ждать любых предложений.

Спасибо

Answer 1

Один вопрос, на который я хотел бы получить ответ, - вам когда-нибудь нужно просматривать данные по всем пользователям для ваших собственных отчетов или использования? В этом случае вам нужно пойти с номером один, иначе у вас будет кошмар, чтобы получить хорошие репортажи.

Будете ли вы делать какие-либо настройки для клиента? Это указывало бы на то, что выделение может быть лучшим выбором. Если вы никогда не будете настраивать, не отделяйте.

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

Я полностью согласен с Олли Джонсом: если вы используете первый вариант, у вас должен быть хороший дизайн защиты базы данных, чтобы клиенты не могли видеть данные других клиентов. Однажды мы переместили клиента с сервера, где он был единственным клиентом, в общую базу данных, и только один процесс, который пропустил запрос client_ID (в старой системе это было не нужно, а разработчики получили небрежные данные), отправил по электронной почте всем торговые представители всех других клиентов с информацией о первом клиенте. Это стоило компании больших денег (как для решения проблемы, так и для рассылки извинений по электронной почте, в результате чего мы почти потеряли клиента и вынуждены были предоставить им несколько перерывов на их содержание), и многие извинялись за извинения, а разработчик - лишь в узких пределах. пропустил потерю работы. Пусть это будет уроком, который ты не выучишь трудным путем.

Answer 2

Это интересный случай конфликта между вашим удобством и вашей ответственностью за безопасность данных ваших клиентов. Для вашего удобства довольно ясно, что мультитенантное приложение, как описано в вашем варианте (1), будет легче всего начать работу.

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

Так что, если вы выберете вариант (1), не сокращайте проверку кода и тестирование безопасности. Если вы проводите плохое тестирование безопасности, вам будет жаль, а хуже и ваших клиентов.

Для большей безопасности вы можете рассмотреть комбинацию опции (2) и (3): единая база кода веб-приложения, перемещающая ваш многопользовательский локус из веб-приложения на сервер MySQL. Система безопасности mySQL неплохо справляется с несколькими арендаторами: Wordpress, Drupal и Joomla все работают таким образом, и все они широко развернуты.

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

Я не говорю, чтобы избежать (1) полностью. Ваш бизнес может предложить решение для размещения нескольких клиентов (вариант 1) с условиями обслуживания для покрытия ваших рисков. А для более крупных или лучше оснащенных клиентов вы можете предложить частное решение.

Answer 3

Лично я бы пошел на кандидата № 3. За исключением части пользователей, такие базы данных могут быстро расти. Чтобы обеспечить максимальную производительность, желательно, чтобы ваши таблицы были как можно меньше. Выбор другой базы данных на основе учетных данных пользователя не должен быть сложным, поэтому логика приложения не должна пострадать.

Я понимаю ваше беспокойство по поводу ремонтопригодности. Каждый клиент живет в одном и том же стеке приложений или у них разные установки? В любом случае, обслуживание должно быть легко сценарием для выполнения нескольких обновлений базы данных. Это не должно вас сдерживать при выборе такого дизайна.

Answer 4

Вам будет намного проще просто использовать одну базу данных. Вы на правильном пути, думая о стоимости обслуживания и т. Д.

Используйте правильно спроектированные / связанные таблицы - например:

Company Information Table
--------
Company_ID (primary key)
Company_Name
Other Fields...


Issue Table
--------
Issue_ID (primary key)
Company_ID (foreign key tied to the Company Information Table)
Issue_Text
Other Fields...

Надеюсь, что помогает

Answer 5

для первой точки

• Чтобы иметь одну большую базу данных для пользователей и одну большую базу данных для cip и использовать идентификатор компании или аналогичный для идентификации отдельных записей компаний в базе данных.

Мое мнение в порядке.потому что базы данных созданы и настроены для хранения и управления большими данными.но только подумайте, что вы должны правильно оформить стол.избежать ситуации дублирования данных и т. д.строить и управлять большим набором данных это хорошо.но следует сосредоточиться на дизайне.Вы должны настроить свои таблицы.для этого вы можете выполнить поиск в Google для разработки базы данных и настройки производительности.

• Чтобы использовать одни и те же HTML-страницы для каждой компании, но выбрать, какую базу данных использовать из данных для входа.Так что каждая компания будет иметь отдельную базу данных CIP, но все компании будут использовать одну и ту же базу данных пользователей.

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

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

попробуйте разработать подобное приложение.

это мои предложения..

Answer 6

Я бы выбрал решение (1) или, если вы думаете, что у вас будут тысячи клиентов, использующих ваше веб-приложение для (2).

(3) определенно станет кошмаром, требующим поддержки.

Кстати, я полагаю, что в решении (1) вы думаете использовать те же html-страницы, что и в решении (2). Используете ли вы большие или маленькие базы данных, я настоятельно рекомендуюв любом случае одна и та же логика приложения (html / php pages) всегда для всех .

Answer 7

только одна база данных для пользователей и компаний будет делать это.и я думаю, что вам понадобятся php, asp или jsp на ваших страницах для идентификации пользователей и запросов к базе данных ...

Answer 8

1. Чтобы иметь одну большую базу данных для пользователей и одну большую базу данных для cip и использовать идентификатор компании или аналогичный для идентификации отдельных записей компаний в базе данных.

Это лучший вариант. Вы можете просто хранить всю информацию в одной базе данных и дифференцировать ее в зависимости от имени пользователя (где вы можете узнать, какой компанией является пользователь и сохранить идентификатор компании в сеансе). Тем не менее, осторожность с вашими кодировками как ошибкой может показать компании некоторую информацию, которой владеет другая компания.

Answer 9

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

Answer 10

Если у вас есть 1 таблица с именем companies, то у каждого пользователя может быть company_id, поэтому он относится к этой компании.Вам нужна только 1 база данных, просто используйте отношение один ко многим.