Автор оригинала: Vlad Mihalcea.
Мы все знаем, что программирование с параллелизмом трудно сделать правильно. Вот почему за потоковыми задачами следуют обширные сеансы проектирования и анализа кода.
Вы никогда не назначаете одновременные проблемы неопытным разработчикам. Проблемное пространство тщательно анализируется, разрабатывается проект, а решение документируется и пересматривается.
Именно так обычно решаются задачи, связанные с потоковой передачей. Вы, естественно, выберете абстракцию более высокого уровня, так как не хотите запутываться в деталях низкого уровня. Вот почему java.util.concurrent обычно лучше (если вы не создаете высокочастотную торговую систему), чем потокобезопасные структуры в стиле Java 1.2, созданные вручную производителем/потребителем.
В системе баз данных данные распределены по различным структурам (таблицам SQL или коллекциям NoSQL), и несколько пользователей могут выбирать/вставлять/обновлять/удалять все, что они захотят. С точки зрения параллелизма это очень сложная задача, и это проблема не только разработчика системы баз данных. Это тоже наша проблема.
Типичный уровень данных СУБД требует от вас овладения различными технологиями, и ваше решение настолько же сильно, насколько и самое слабое место вашей команды.
Когда дело доходит до программирования баз данных, вы никогда не должны оставаться неподготовленными. Постоянное обучение-ваше лучшее оружие, другого пути нет.
Для этого я придумал свой собственный стек знаний о данных:
Вы всегда должны осваивать нижние слои, прежде чем переходить к верхним.
Итак, это золотые правила укрощения уровня данных:
- Руководство по базам данных предназначалось не только для администраторов баз данных
Если вы выполняете какую-либо задачу, связанную с базой данных, чтение текущего руководства по базе данных необязательно. Вы должны быть знакомы как со стандартом SQL, так и с особенностями вашей базы данных. Освободитесь от мышления SQL-92 . Не позволяйте страху переносимости заставить вас отказаться от высокоэффективных специфичных функций базы данных. Чаще всего в итоге получается медленный уровень базы данных, чем перенос уже работающей системы на новое решение для баз данных.
- Полностью прочитайте “ Шаблоны архитектуры корпоративных приложений “
Я дам вам отличный совет по инвестициям. Вы находитесь на расстоянии 50 долларов от понимания основных концепций любого доступного инструмента ORM. Книга Мартина Фаулера обязательна для любого корпоративного разработчика. Каталог онлайн-моделей – отличный тизер.
- Ознакомьтесь с документацией ORM
Некоторые утверждают, что их инструмент ORM является корнем всего зла. Если вы не потратите свое время и не прочтете всю доступную документацию, вам будет очень трудно укротить свой уровень данных ORM. Несоответствие объекта отношениям всегда было действительно сложной проблемой , но это упрощает операции СОЗДАНИЯ/ОБНОВЛЕНИЯ/УДАЛЕНИЯ сложных древовидных структур объектов. Функция оптимистичной блокировки ORM-отличный способ справиться с проблемой потерянного обновления .
- Выберите и смешайте
JPA/Hibernate не являются заменой SQL. Вы должны взять лучшее из JPA и SQL и объединить их в одно выигрышное решение. Поскольку SQL неизбежен в любом нетривиальном приложении, разумно потратить некоторое время (и, возможно, лицензию) на использование мощной платформы запросов . Если вы опасаетесь, что переносимость базы данных мешает вам использовать собственные функции запросов к базе данных, то комбинация JPA/QueryDSL-это рецепт успеха.