Несколько вопросов о дизайне базы данных, связанных с пользовательским контентом сайта

Question

Разработка веб-сайта с пользовательским контентом (вроде похожего на yelp, но для другого рынка и с обменом фотографиями), и у него было мало вопросов о базе данных:

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

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

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

4. Если все вышеприведенное верно, это означает, что мы поддерживаем 1 основной набор таблиц со значениями системы по умолчанию, тогда каждый пользователь получит одинаковое значение, скопированное в их таблицы? В некоторых полях, например, указано Максимальное количество неудачных попыток входа в систему, прежде чем система заблокирует учетную запись. У нас по умолчанию 5 попыток входа в систему в течение 30 минут. Но я хочу разрешить пользователям также указывать свой собственный номер, чтобы настроить выигрышную безопасность, так что это означает, что они могут перезаписать системное значение по умолчанию в своей собственной таблице?

   Спасибо.

Answer 1

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

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

Это позволяет вам видеть таблицу как 1 объект, хотя она логически разделена - СУБД выполняет большую часть работы и представляет вам 1 объект. Таким образом вы выбираете, вставляете, обновляете, изменяете и т. Д. Как обычно, и БД определяет, к какому разделу относится SQL и выполняет команду.

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

Вот ссылка на таблицы секционирования (для SQL Server): http://databases.about.com/od/sqlserver/a/partitioning.htm

Answer 2

1. Пользователи не должны получать свой собственный набор таблиц.Скорее всего, он не будет работать так же хорошо, как одна таблица (правильно проиндексированная), и изменения схемы придется развернуть в всех пользовательских таблицах.
2. В таблице могут быть указаны значения по умолчаниюдля вещей, которые не являются обязательными.
3. С трудом.С одним набором таблиц это будет намного проще и, вероятно, быстрее.
4. Данные такого рода должны храниться в таблице пользовательских настроек, в которой хранятся все настройки для всех пользователей.Опять же, не дублируйте схему для всех пользователей.

Answer 3

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

Распространенным подходом для очень больших сайтов является разбиение базы данных . Сводка такова: у вас есть N экземпляров вашей базы данных параллельно (на отдельных машинах), и каждый содержит 1 / N всех данных. Есть некоторый общий способ узнать, какой экземпляр содержит данный бит данных. Для доступа к некоторым данным у вас есть 2 шага, а не 1, который вы ожидаете:

1. Определите, какой осколок содержит данные
2. Перейти в этот осколок для данных

Есть проблемы с этим, например: вы настроили, например, 8 осколков, и все они заполняются, так что вы хотите поделиться данными, например, 20 осколков -> перенос данных между осколками.

Answer 4

Похоже, вам нужно найти учебник по основам проектирования реляционных баз данных. Независимо от типа приложения, которое вы разрабатываете, вы должны начать с него. Узнайте, как работают объединения, индексы, первичные и внешние ключи и т. Д. Узнайте о базовой нормализации базы данных.

Не принято создавать новые таблицы на лету в приложении; это обычно не нужно в правильно разработанной схеме. Обычно изменения схемы выполняются во время развертывания. Единственный раз, когда «пользователи» получают свои собственные таблицы, это артефакт решения о предоставлении, в котором каждый «пользователь» фактически является арендатором в огороженном саду; это имеет смысл только в том случае, если каждому «пользователю» (скорее всего, компании или организации) никогда не требуется доступ к чему-либо, что было сохранено другими пользователями в системе.

Существуют механизмы для работы со слабо структурированными типами информации в базах данных, но если вы обнаружите, что часто достигаете этого (самый распространенный метод называется Entity-Attribute-Value), ваша проблема либо не совсем правильно смоделирована, на самом деле вам может не понадобиться реляционная база данных, и в этом случае лучше использовать документно-ориентированную базу данных, например CouchDB / MongoDB.

Добавление на основе ваших обновленных комментариев / заметок:

Ваши опасения по поводу количества записей в конкретной таблице, скорее всего, преждевременны. Получите что-то работающее в первую очередь. Большинство современных СУБД, включая более новые версии MySql, поддерживают механизмы помимо индексов и кластеризованных индексов, которые могут помочь в работе с большим количеством записей. Например, в MS Sql Server вы можете создать функцию разбиения по полям таблицы; MySql 5.1+ имеет несколько похожих опций разделения, основанных на хэш-функциях, диапазонах или других механизмах. Следуйте устоявшимся соглашениям по проектированию баз данных, максимально разумно моделируя свой домен, а затем адаптируйтесь, когда сталкиваетесь с проблемами. Сначала настройте, используя инструменты, доступные в выбранной вами базе данных, затем рассмотрите более радикальные меры только тогда, когда вы сможете доказать, что они необходимы. Существуют другие виды денормализации, которые, скорее всего, будут иметь смысл, прежде чем вы даже захотите подумать о том, чтобы иметь нечто столь же однотипное для систем баз данных, как модель «таблица на пользователя»; даже если бы я посмотрел на этот маршрут, я бы сначала рассмотрел что-то вроде материализованного представления.

Answer 5

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