Каков лучший дизайн базы данных для тысяч строк

Question

Я собираюсь запустить Database Design , который будет просто управлять пользователями в компаниях.

• Каждая компания будет иметь административную область, которая может управлять пользователями
• В каждой компании будет около 25 000 пользователей
• Клиент считает, что для начала потребуется около 50 компаний

Мой главный вопрос

Должен ли я создать таблицы на основе компаний?как

users_company_0001 users_company_0002 users_company_0003 ...

, поскольку каждая компания никогда не будет использовать "других" пользователей, и ничто не должно будет суммировать / считать разные таблицы во всех user_company (aпростой JOIN сделает свое дело, хотя это дороже (раз), он будет работать как с основной картинкой, это никогда не понадобится.

или я должен просто создать a users таблица для (50 x 25000) 1 250 000 пользователей (и растет).

Я думаю о первом варианте, хотя я не уверен, как бы яиспользовать Entity Framework на таком макете ... Мне, вероятно, нужно вернуться к 90-м годам и сгенерировать мой уровень логики данных вручную.

если это будет простой вызов процедур хранения, содержащих идентификатор компании

Что вы посоветуете?

Системное приложение будет ASP.NET (вероятно, MVC, я все еще пытаюсьчтобы понять это, поскольку все мои знания о веб-формах, хотя я видел видео Скотта Хансельмана MVC - швы легко - ноЯ знаю, что это будет не так просто, так как проблемы возникнут, и я потрачу больше времени на их устранение), а также Microsoft SQL .

Answer 1

Даже несмотря на то, что вы описали это как отношение «один ко многим», я бы все равно разработал базу данных как «многие ко многим», чтобы предотвратить будущие изменения требований. Что-то вроде:

Answer 2

Работая с многотерабайтной базой данных SQL Server и имея опыт работы с сотнями таблиц в течение моей карьеры с многомиллионными строками, я могу с полной уверенностью сказать, что SQL Server может обрабатывать ваши companyи users таблицы без разбиения.Он всегда рядом, когда вам это нужно, но ваше беспокойство не должно касаться ваших таблиц - выберите простейшую схему, которая соответствует вашим потребностям.Если вы хотите что-то сделать для оптимизации производительности, вашим узким местом наверняка будут ваши диски.Не покупайте большие, медленные диски.Возьмите себе кучу маленьких дисков с высоким числом оборотов в минуту и ​​распределите по ним как можно больше своих данных, и не делитесь дисками со своими журналами и данными.С базами данных вам почти всегда лучше добиться производительности с хорошим оборудованием, хорошей дисковой подсистемой и правильной индексацией.Не идите на компромисс и не усложняйте свою схему, пытаясь предвидеть производительность - вы об этом пожалеете.Я видел действительно большие базы данных, где такие вещи были необходимы, но твоя не так.

Answer 3

re: Должен ли я создавать таблицы на основе компаний? да

как

users_company_0001 users_company_0002 users_company_0003

нет, как

companyID  companyName, contactID

или я должен просто создать таблицу пользователей, чтобы иметь (50 x 25000) 1 250 000 пользователей (и растет) да

Answer 4

Я думаю, вы должны создать отдельные таблицы для компании и пользователя. затем третья таблица для соединения двух: CompanyAdmin. Что-то вроде:

• Company ( Company_Id , Company_name, ...)
• Пользователь ( Идентификатор пользователя , Имя пользователя, ...)
• CompanyAdmin ( Company_id , User_id)

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

При правильном индексировании объединение стоит в базе данных, содержащей несколько миллионов строк не должны быть проблемой.

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