Это плохая идея иметь таблицу свойств в базе данных? - PullRequest
Новая
       10

Это плохая идея иметь таблицу свойств в базе данных?

7 голосов
/ 23 февраля 2010

Часто, когда мне нужно сохранить системные свойства, такие как информация администратора, версии и т. Д., Я использую плоский файл (database.properties, init.properties и т. Д.). Это кажется распространенным в других программах, которые я вижу и использую ежедневно.

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

property_entry_table 

[id, scope, refId, propertyName, propertyValue, propertyType] 
1, 0, 1, "DB_VER", "2.3.0", "FLOAT"  
2, 0, 1, "LICENCE", "88475", "INT"  
3, 0, 1, "TOP_PROJECT", "1", "INT"   
4, 0, 1, "SHOW_WELCOME", "F", "BOOL"  
5, 0, 1, "SMTP_AUTH", "SSH", "STRING"  
6, 1, 1, "ADMIN_ALERTS", "T", "BOOL"

Я понимаю, что это нарушает типизацию SQL и позволяет мне хранить все виды типов в виде строк. Это хорошая практика или я поступил неправильно?

Если нет, каким образом я должен хранить информацию такого типа?

Ответы [ 3 ]

2 голосов
/ 23 февраля 2010

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

1 голос
/ 23 февраля 2010

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

0 голосов
/ 23 февраля 2010

Это хорошо для небольших объемов редко используемых данных.

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

Это уменьшает проблемы с обновлениями схемы. (Свойства приложения часто добавляются / удаляются.)

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

...