Классика баз данных - статьи
Критерий простоты программирования учетной системы.
С точки зрения дизайна пользовательского интерфейса логично было бы предположить, что проще вводить информацию в электронном табеле таким же образом, как это делается в бумажном документе. Т.е., напрашивается табличная форма ввода, в общих чертах повторяющая табель (Рис 1.).
Запросы для получения данных в эту форму:
- Модель А:
SELECT idTabel, idPaymentType, idPerson,
SUM(CASE DAY(Date) WHEN 1 THEN Hours ELSE 0 END) AS h1,
SUM(CASE DAY(Date) WHEN 2 THEN Hours ELSE 0 END) AS h2,
...
SUM(CASE DAY(Date) WHEN 31 THEN Hours ELSE 0 END) AS h31
FROM tblTabelFact
GROUP BY idTabel, idPaymentType, idPerson
WHERE idTabel = @idTabel- всего 35 строк. Можно конечно принять решение о разворачивании данных не в SQL-запросе, а в программном коде, но вряд ли это будет проще.
- Модель Б:
SELECT idTabel, idTabelRow, idPerson, idPaymentType, h1, h2, h3, h4, h5, h6, h7, h8, h9, h10,
h11, h12, h13, h14, h15, h16, h17, h18, h19, h20,
h21, h22, h23, h24, h25, h26, h27, h28, h29, h30, h31
FROM TabelRow
WHERE idTabel = @idTabel
Разница очевидна: запрос в модели А значительно сложнее. Это еще сильнее проявляется для запросов модифицирующих данные: если для модели строк подходят стандартные механизмы сохранения данных таблицы (грида), то для модели фактов придется изобретать свои методы – задача конечно же решаемая, но все же нетиповая. Причем именно усложнение программирования модификации данных здесь позволяют сделать выбор в пользу модели Б, ведь, как уже говорилось выше, модели эквивалентны –можно создать представление (view) и пользоваться в модели А коротким запросом как в модели Б.
