Comments 12
В случае с таблицами dbo.format_profile и dbo.format_history я бы поступил немного иначе. В таблицу dbo.format_profile добавил бы первичный ключ типа int, а в таблице dbo.format_history сделал бы внешний ключ так же типа int. Это немного увеличило бы размер таблиц, но в случае соединения таблиц при выборке дало бы большую производительность запросов, так как операции по считыванию с диска и размещению данных в buffer cache происходили бы по данным типа int (4 байта), а не BINARY(16) (16 байт).
Замечание верное. Так изначально и планировалось, но как-то не срослось, потому что перед вставкой нового профиля делается проверка — существует ли уже такой профиль в таблице. Делать это по хешу оказалось быстрее.
Я не писал, что поле с хешем не нужно, пусть оно остается. Как раз при вставке новой записи оно и потребуется. Я писал, что соединять две таблицы по хешу менее оптимально, чем по полю с типом int.
Вначале просто не о том подумал. Да такой вариант был бы быстрее.
Вот вам и еще одно исключение из правила «избегайте избыточности данных». Вроде уникальность можно и по хешу проверить, а с добавлением еще одного столбца повышается скорость.
А есть желание возможность написания статьи о правильности проектирования БД не только с позиции lightweight tables, а в целом? И желательно оторваться от конкретики (postgre, micro sql, oracle and etc)?
p.s. забыл знак вопроса поставить :-)
p.s. забыл знак вопроса поставить :-)
Sign up to leave a comment.
Lightweight Tables или практические советы при проектировании БД…