1 или много таблиц sql для сохраняющихся «семейств» свойств об одном объекте?

Question

Наше приложение (использующее серверную часть SQL Server 2008 R2) хранит данные об удаленных аппаратных устройствах, отправляя отчеты на наши серверы через Интернет. У нас есть несколько «семейств» информации о каждом устройстве, каждое из которых сохраняется отдельным серверным приложением в общей базе данных:

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

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

Наибольшее количество экземпляров устройств, о которых нам нужно беспокоиться, будет около 100 000, так что это не проблема «больших данных». В большинстве случаев в базе данных должно быть не более 10 000 устройств.

Запись в данные об отдельном устройстве происходит нечасто - обычно каждые несколько часов. Теоретически это возможно для запланированной задачи, введенных пользователем изменений конфигурации и динамических данных для всех обновлений для одного и того же устройства в одно и то же время, но это кажется очень редким. Чтения происходят чаще: вероятно, 10 раз в минуту чтения по крайней мере с одного устройства в базе данных и несколько раз в час для полного сканирования некоторых свойств всех устройств, описанных в базе данных.

Удаление происходит относительно редко, на самом деле во многих случаях мы используем только «мягкое» удаление устройств, поэтому мы можем использовать их для создания исторических отчетов. Новые устройства вставляются чаще, возможно, несколько каждый день.

Есть (как минимум) два очевидных способа хранения этих данных в нашей базе данных SQL:

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

Мой вопрос: есть ли явно лучший вариант? Если ответ «это зависит», то какие обстоятельства могут сделать «одну большую таблицу» или «несколько таблиц» лучше?

Ответы должны учитывать: производительность, ремонтопригодность самой БД, ремонтопригодность кода, который читает / записывает строки, и надежность в условиях непредвиденного поведения. Ремонтопригодность и надежность, вероятно, для нас важнее, чем производительность, если мы вынуждены идти на компромисс.

Answer 1

Не знаю о явно превосходном варианте, и я не знаю об архитектуре sql-сервера. Но я бы выбрал первый вариант с отдельными таблицами для разных семейств данных. Некоторые преимущества могут быть:

• предоставление доступа к определенным наборам данных (может быть желательно для будущих приложений)

• архивирование разных ошибок данных с разной скоростью

• частичная функциональность приложения в случае обслуживания части (некоторые таблицы доступны, а другая восстановлена)

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

• разные семейства могут быть назначены разным областям кэша (таким образом, статические данные могут оставаться в более «статическом» кэше, а более быстро изменяющиеся данные типа регистрации могут находиться в другой «катящейся» области кэша)

• меньшие строки упаковывают больше строк в блок, а это означает, что меньше блоков извлекается для сканирования таблицы на предмет определенного атрибута

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

• легче понять данные при разделении на логические единицы (семейства)

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

Answer 2

Первый вариант - это общепризнанный «стандартный» способ хранения таких данных в реляционной базе данных.Хотя хороший дизайн, вероятно, приведет к большему числу таблиц.Программное обеспечение для реляционных баз данных, такое как SQLServer, было разработано для быстрого и эффективного хранения и извлечения данных из нескольких таблиц.

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

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

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