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

Question

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

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

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

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

Answer 1

Магия.

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

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

Answer 2

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

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

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

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

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