Архитектор информационных систем и баз данных. Ful
Для каждого свойства надо определить его тип и соответственно привязать алгоритм записи-чтения, интерфейс и систему хранения в зависимости от типа. Эта проблема в целом относиться к работе с метаданными и метаалгоритмам.
Архитектор информационных систем и баз данных. Ful
Делаете таблицу с атрибутом DECIMAL, а на нее ссылку по ключу из таблице где в записи рейтинг. Потом JOIN LEFT и получаете Ваш рейтинг с одной стороны, а SELECT по ней варианты значений рейтинга с другой стороны для фронтэнда.
Таблицу при инсталляции надо как раз Вашими значениями и заполнить.
Архитектор информационных систем и баз данных. Ful
Для данных фиксированной длины, лучше использовать поля фиксированной длины. База будет эффективней работать. Это по производительности. А с точки зрения целостности данных база - последняя линия обороны. Поэтому лучше чтобы параметры полей соответствовали проекту. А то потом где-то всплывет что-нибудь. Или будет глючить неуловимо.
Архитектор информационных систем и баз данных. Ful
Например так:
Таблица "Очередь обновлений записей" - запись обновилась туда вставляете запись с новой версией записи.
Потом по этой таблице пробегаете периодически и на серваки раскладываете апдейты.
Архитектор информационных систем и баз данных. Ful
Поставьте себе WordPress,Joomla или Drupal и не углубляетесь в эти дерби.
Главное обновляйте регулярно и храните бэкапы, чтобы криптолокеры на поймали.
Архитектор информационных систем и баз данных. Ful
Конечно нормализованные. На денормализованных таблицах у Вас Join не будет и Вам придется либо синхронизировать теоретически идентичные данные в разных полях, либо пилить свой движок SQL.