Масштабируемость базы данных: что важнее, размер таблицы или количество запросов? - PullRequest
Новая
       27

Масштабируемость базы данных: что важнее, размер таблицы или количество запросов?

2 голосов
/ 31 мая 2011

В качестве примера я возьму упрощенную систему StackOverflow.

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

(Django-esque pseudo-code)

QA table:
    parent = ForeignKey(self)
    category = ForeignKey(Category)
    title = CharField()
    description = TextField()

Тогда, чтобы получить Вопросы и Ответы на Вопрос с ID 1, SQL SELECT будет сделан для id==1 или parent==1.Недостатком может быть то, что поля tags и title не используются Ответами

Альтернативой, конечно, могут быть две таблицы: 

Questions:
    category = ForeignKey(Category)
    title = CharField()
    description = TextField()

Answers:
    parent = ForeignKey(Questions)
    description = TextField()

, которые потребуют два запроса дляполучите вопросы и ответы.

Инстинкт говорит, что первое - ужасная идея, но я не уверен почему.

Что быстрее и масштабируемее?

Ответы [ 2 ]

2 голосов
/ 31 мая 2011

Чтобы ответить на ваши вопросы напрямую, ваш инстинкт верен.Смешивать сущности (Вопросы и Ответы) в одну таблицу - почти всегда плохая идея.Логически они являются двумя отдельными объектами, и физически они должны храниться отдельно.

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

2 голосов
/ 31 мая 2011

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

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

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

...