Действительно ли это - плохая идея иметь таблицу свойства в базе данных?
Часто, когда я должен сохранить системные свойства как информация об администраторе, версии, и так далее, я использую плоский файл (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 ответа
Я использовал аналогичную структуру для хранения данных о свойствах, и я думаю, что это нормально, если таблица останется относительно небольшой. Таблица значения атрибута объекта ( EAV ), подобная этой, может занимать больше места и демонстрировать более низкую производительность запросов, чем традиционная таблица со структурой столбцов, но это не должно быть проблемой для набора таблиц разумного размера. свойства приложения.
Я думаю, что это нормально, но вы можете подумать о кешировании данных в памяти, когда вы их читаете, чтобы вам не приходилось возвращаться к БД. Если вы кешируете свои данные, храните их в любом месте, что упростит вам обновление. Преимущество размещения данных в вашей БД состоит в том, что может быть проще поддерживать или создавать интерфейсы для управления этими свойствами, особенно после того, как вы начнете использовать распределенную среду для своего приложения.
Это подходит для небольших объемов данных с очень редким доступом.
На самом деле для пользователя, просматривающего схему, может быть лучше не видеть отдельные свойства приложений.
Это уменьшает проблемы с обновлением схемы. (Свойства приложений часто добавляются/удаляются.)
Для чего она не подходит, так это для больших объемов данных или данных с частым доступом, так как в этом случае базе данных приходится выполнять гораздо больше работы по извлечению данных и занимать больше места, чем при использовании обычной схемы.