12  /  96

Архитектура Базы данных

Просмотров: 1869 (Статистика ведётся с 06.02.2017)
Дата последнего изменения: 18.09.2018

Есть несколько схем работы с БД.

Работа с БД напрямую, через функции PHP, обеспечивает скорость разработки, гибкость, но вызывает сложность поддержки. Такие проекты делаются быстро, в срок, но ими сложно пользоваться и сложно их поддерживать. Можно рекомендовать для простых проектов, для больших и средних - не рекомендуется.

Схема работы через прослойку, реализованную на основе шаблона проектирования TableModule. В этом случае работа с базой данных идёт через какой-то класс, через какой-то объект. Этот объект представляет собой интерфейс доступа к таблице. Преимущество такого подхода в том, что работа с БД инкапсулируется в каком-то классе, какой-то сущности. И любые модификации идут через эту сущность. При этом упрощается развитие, поддержка и эксплуатация проекта. Недостаток в том, что такая реализация сложнее, если проект разрабатывается без какого-либо фреймворка, где это уже реализовано.

На проектах со сложной предметной областью, со сложными сущностями иногда полезно использовать ORM. Конкретнее, паттерны:

  • ActiveRecord, где объект представляет собой запись в таблице, позволяющий успешнее решать задачи большой и сложной предметной области со связями. Недостаток: большой объём кодирования, но можно использовать библиотеки.
  • DataMapper, где объекты не знают о БД ничего, есть только объекты и их свойства. Программисту легко реализовывать бизнес-логику в таких условиях, а за работу с БД отвечает слой DataMapper.
Внимание! Любые библиотеки по работе с БД увеличивают расходы. У TableModule - накладные расходы минимальные, у DataMapper - максимальные. Поэтому DataMapper рекомендуется только для сложных областей, но не для высоконагруженных.

На этапе разработки архитектуры надо подумать о горизонтальном масштабировании Базы данных, потом может быть поздно. О веб-кластере надо задумываться уже на этапе прототипа, если проект большой и высоконагруженный. Оптимальнее всего, как всегда, использовать какой-нибудь фреймворк, который уже умеет это делать, чем самостоятельно решать вопросы:

  • Репликация. Вопрос решаемый и не сложный.
  • Кластеризация кода. Самый сложный вопрос в кластеризации - это кластеризация сессий и кеша. Сессии можно хранить либо в базе либо в memcache.
  • Как будут решаться вопросы нагрузки и распределения. Может через NGINX, может как-то по другому.
  • Как хранить и отдавать статику. Использовать ли CDN?
  • Авторизация.
  • Шардинг. Если проект очень большой, это может потребоваться.

Что выбрать?

Для слабых и средних команд рекомендуется использовать какой-то фреймворк, с которым лучше всего знакома команда. Это убережёт от множества проблем и рисков и сократит затраты на разработку проекта. За счёт того, что фреймворк даёт готовую архитектуру. Её не надо писать, она уже есть.

Сильные команды с немалым опытом могут позволить себе разработку "с нуля", если... если им это позволит клиент по срокам и финансированию.




4
Курсы разработаны в компании «1С-Битрикс»

Если вы нашли неточность в тексте, непонятное объяснение, пожалуйста, сообщите нам об этом в комментариях.
Развернуть комментарии