Разработка и дизайн хорошего уровня данных: каковы распространенные плохие практики в разработке уровня данных?

Question

В настоящее время я изучаю лучшие практики (на достаточно высоком уровне) для разработки приложений для систем с высокой степенью обслуживания, что приводит к минимальному трению к изменениям. Под «уровнем данных» я подразумеваю проектирование базы данных, сопоставителей объектных связей (ORM) и общие технологии доступа к данным.

Исходя из вашего опыта, что вы считаете распространенными ошибками и плохой практикой, когда речь идет о разработке уровня данных, и какие меры вы приняли / внедрили / или можете рекомендовать, чтобы сделать уровень данных лучшим местом для с точки зрения разработчика?

Пример ответа может включать: Каковы наиболее распространенные причины медленных, плохо масштабируемых и расширяемых уровней данных? + Какие меры могут быть приняты (будь то при разработке или рефакторинге) для решения этой проблемы?

Я ищу военные истории и некоторые реальные советы, которые я могу встроить в общедоступные руководящие документы и образцы.

Answer 1

Magic.

Я использовал Hibernate , который автоматически сохраняет и выбирает объекты из базы данных. Он также поддерживает отложенную загрузку, поэтому связанный объект извлекается из базы данных только по запросу. Это работает каким-то волшебным образом, я не понимаю.

Все это работает нормально, пока работает, но когда оно выходит из строя, его невозможно отследить. Я думаю, что у нас была проблема, когда мы комбинировали Hibernate с AOP , что каким-то образом объект еще не был инициализирован Hibernate при выполнении нашего кода. Эту проблему было очень трудно отладить, потому что Hibernate работает такими загадочными способами.

Answer 2

Объектно-реляционное отображение - плохая практика. Под этим я подразумеваю, что он имеет тенденцию создавать схемы данных, которые можно только в общих чертах описать как «реляционные», и поэтому они плохо масштабируются и демонстрируют плохую целостность данных.

Это потому, что должным образом реляционные схемы прошли процесс нормализации, тогда как результаты O-R Mapping обычно представляют собой классы объектов, реализованные в виде таблиц базы данных. Обычно они не нормализуются, а предназначены для немедленного удобства разработчика OO.

Конечно, в случаях, когда постоянные требования к данным минимальны, это неважно.

Однако однажды я работал в судоходной компании, которая выросла за счет поглощения нескольких других компаний и поручил разработку интегрированной операционной системы (для замены различных систем, унаследованных ею), компании, унаследованной от компании. методология, со схемой данных, созданной с помощью сопоставления OR. Характеристики производительности разрабатываемой системы были настолько плохими, а схема данных - настолько сложной, что судоходная компания отказалась от нее после двух лет разработки, прежде чем она вообще заработала!

Это было прямым следствием отображения O-R; Наихудшая сложность схемы (и, следовательно, низкая производительность) была вызвана существованием таблиц, созданных исключительно как артефакты процесса проектирования ОО - они отражали схемы экрана, а не отношения данных.