В последнее время я всерьёз озадачен отношениями кода и данных. Есть множество систем управления данными: реляционных и безэскуэльных. Разработчики ломают копья, выясняя, какая из них быстрее пишет и читает данные, расходует меньше оперативной памяти, проводит меньше дисковых операций. Но во времена, когда «Ватсон» закончил медвуз и отправился лечить людей, ни одна популярная система управления данными не может проанализировать лог запросов к самой себе и банально расставить нужные индексы. Вместо этого она предоставляет мегатонны отличного конфига с миллиардом настроек, предлагая администраторам продираться через дебри ридми, хауту и факъю.
Я применяю концепцию полной абстракции от СУБД, где данные представлены в коде, как объекты и связи между ними. Объект — представление строки из таблицы в виде класса со свойствами, соответсвующими её полям. Связь — представление таблицы, которая хранит идентификаторы связаных объектов. Очень важно, что связи не хранятся в самих объектах, так как по умолчанию они все «многие‑ко‑многим» и не имеют направления.
Вся работа с объектами и связями осуществляется через веб‑интерфейс. Одним из приятных бонусов является удобное распространение изменений. Помимо изменения базы данных, веб‑интерфейс ведёт лог изменений базы данных в формате эскуэль‑запросов. Этот лог используется в другой копии проекта для применения этих изменений. Процесс запускается два раза. Первый — «сухой прогон», изменения симулируются. Система проверяет, нет ли конфликтов. Если нет, то запускает второй прогон и изменяет базу данных. Если конфликты есть, то выводит их описание и останавливает процесс.
По моему опыту, большинство конфликтов случается из‑за несоблюдения технологического процесса и гайдлайнов разработки. Предупредить их можно хорошим фреймворком. И я говорю не
Это был совет о разработке программных интерфейсов. Хотите узнать всё об умной вёрстке, правильных скриптах, грациозной деградации, трюках и работе технолога с дизайнером? Присылайте вопросы.