Добрый день Друзья, есть пара вопросов - помогите, пожалуйста: У объекта есть свойства... В данный момент все свойства не могут быть классифицированы, какие-то добавятся позже, в общем нет конечного списка. Свойства имеют разные единицы измерения, некоторые просто текстовые. Думаю в БД это сделать следующим способом: -таблица "Справочник свойст" id, svoistvo_id, (нужен, т.к. предполагается мультиязычность) name, measure_id, is_measure, (имеет единицу измерения?) lang_id -таблица "Объект-Свойства" id, (нужен ли отдельный айдишник или включить в ключ ид объекта, свойства и дату?) date_prisvoenie, (значение свойства действует с) value (VARCHAR!), is_actual, (значение часто меняются - нужно для быстрого отлова последней актуальной версии) object_id, svoistvo_id Подскажите - имеет ли такая схема право на жизнь?
BeInspired Я всегда стараюсь хранить разнородные данные в разных полях таблицы. Появляется новое свойство - добавляется новое поле в таблицу (через ALTER TABLE). Свойство стало ненужным - поле удаляется. Вместо трех таблиц достаточно одной, выборки тоже становятся проще. Главный минус такого подхода - при добавлении свойства приходится, по сути, пересоздавать всю таблицу. Если в ней много данных - на это потребуется время. P.S.: Это не по MySQL вопрос.
БД будет на MySQL, поэтому сюда воткнул... Т.е. вы храните свойства объекта по сути в одной таблице с объектом? Если так, то как вы отслеживаете историю изменения значения свойства?
BeInspired С такой экзотикой не сталкивался, скорее всего для хранения всех предыдущих свойств понадобится отдельная таблица-лог. Там так же изящно хранить данные не получится (колво изменений у разных свойств различно), так что будет что-то вроде вашего варианта. Таблица работает по схеме: как только у объекта меняется некоторое свойство - предыдущее значение свойства сохраняется в логе (в таблицу лога добавляется новая запись), а в основной таблице значение меняется на новое. Но учтите, если у вас много объектов и много свойств, да еще и значения их часто меняются - вы захлебнетесь в этих логах, какую бы структуру ни спроектировали. Логировать надо только действительно важные данные (например, объекты целиком после наиболее важных изменений).
Согласен, что историю хранить надо по наиболее важным параметрам, но тут такая ситуация, что пользователю необходимы будут отчеты по всем свойствам. Вот думаю подумать насчет ваших слов, что актуальную версию свойств хранить в отдельной таблице - пусть немного дольше будут отрабатывать изменения свойств, зато быстрее будут идти считывания текущих значений.