Samotnik,
Вы бы тогда пояснили, что лежит в device_id и какой объем информации предполагается хранить в men, а то с ходу придумывается сразу два решения - денормализация men по device_id или отдельная таблица для статистики, опять же, или совсем без device_id или с денормализованным значением.
"Эти слова уже не первый человек говорит. Неужели все так плохо."
Ну как вам сказать, это все равно как спор нужен ли нормальный генератор экранных форм в JAVA?
Для quick and dirty решений несомненно нужен и очень обидно, что сообщество JAVA долгое время почему-то полагало совсем иначе, да и сейчас не все так гладко, по крайней мере те генераторы, что я видел (а видел я их мало, так что, возможно, не прав) хуже чем в Delphi 2.
Так и с каскадным удалением - если пишем приложение с тройкой табличек, зачастую будет разумно задействовать это решение, отдавая себе отчет в его непрочности.
Опять же, для большинства нормальных СУБД для каскадного удаления Hibernate и нафиг не нужен.
В Hibernate вообще часть решений связана с тем чтобы обеспечить универсальность в тех областях, которые на практике нужны 0,01% разработчиков, да и тем неясно зачем.
Например, Oracle, Ms SQL, DB2, MySQL (InnoDB), Firebird, Interbase, PostgreSQ, Apach Derby, Cloudscape, думаю при желании можно вспомнить еще десяток, поддерживают ON DELETE CASCADE "из коробки", причем это решение принимается на этапе создания архитектуры и для этого не надо загаживать JAVA код не нужными аннотациями.
Hibernate хорош там, где надо отобразить плоские реляционные таблицы на объекты, во всем остальном для проектов всерьез использующих работу с СУБД, надо быть очень осторожным, полагаясь на его услуги, но могут оказаться медвежьими.  |
