Методы хранения данных

Недавно я начал читать книгу "Programming Semantic Web" издательства O'Reilly. В первой главе книги описываются различные подходы хранения данных. Эти вопросы мне кажутся актуальными для каждого, кто хоть раз более менее серьезно сталкивался с базами данных. Какую схему выбрать, какие должны быть связи между таблицами, какой формат полей, какова будет производительность базы данных при такой схеме ... и много, много других подобных вопросов. Поначалу я делал просто просто краткие заметки, что называется "на полях". Но потом как-то неожиданно для меня самого они переросли в этот пост.

Методы представления данных

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

Табличное представление. Простейший вид представления данных. Большинство из нас хорошо знакомы с этим представлением данных. Примером являются таблицы Excel. Эти данные легко читаются, с ними легко работать. Большинство "баз данных" в бизнес среде как раз представлены простыми Excel таблицами. Мне часто приходилось и приходится видеть, как при наличии большого количества специализированных приложений, люди все равно пользуются excel-таблицами. С ними действительно легко работать. Но данные представленные в данном виде имеют также и ряд недостатков. Например, в таблицах с описанием магазинов, время работы представлено в виде одного поля: понедельник, вторник, среда (11-16:00), четверг (11-19:00), пятница (11-20:00). Это читабельно для человека, но в этом случае достаточно сложно сделать выборку всех магазинов, которые скажем работают в пятницу до 21:00. Конечно эксперты Excel могут написать макрос для решения данной задачи, но большинство людей не пишут макросы.

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

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

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

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

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

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

Есть ли выход?

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

Обычно данная схема не рекомендуется, т.к. она приводит к снижению производительности базы данных. Это плата, которую придется заплатить за гибкость. Мы легко можем добавить новые поля и свойства объекту.


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

Выбор каждый делает сам ...