Pull to refresh

Разворачивание широкой таблицы в столбец (EAV pattern)

SQL *

Задача


Есть сущность, которая характеризуется огромным и часто переменным числом параметров. Задача хранить эти сущности да еще и так чтоб поиск тоже можно было вести желательно еще и с построением индекса.
Читать дальше →
Total votes 42: ↑29 and ↓13 +16
Views 26K
Comments 65

Подобие LINQ на PHP для EAV модели хранения данных

PHP *Programming *SQL *
Увидев пост о LINQ на PHP, я решил незамедлительно поделиться своими наработками в этой области.
Моей реализации далеко до полноценного LINQ, но в ней присутсвует наиболее заметная черта технологии — отсутвие инородной строки запроса.
Читать дальше →
Total votes 10: ↑6 and ↓4 +2
Views 5.4K
Comments 8

Делаем простейший фильтр по свойствам товаров с помощью ElasticSearch на Symfony2

Website development *PHP *Symfony *
Tutorial
Написать эту статью меня сподвигло отсутствие в интернете готового пошагового руководства «как реализовать фильтр товаров на ElasticSearch», а задача сделать это у меня стояла чётко и непоколебимо. Удавалось находить отрывочную справочную информацию, но никак не cookbook по решению самых тривиальных задач.

Акцентирую ваше внимание именно на symfony2, поскольку буду использовать FOSElasticaBundle, который позволяет описывать mapping индексов elasticsearch в удобных yaml конфигах и привязывать к ним сущности Doctrine ORM или документы Doctrine ODM. Промаппленные индексы заполняются из связанных доктриновских сущностей с помощью одной единственной консольной команды. Кроме того, он включает в себя вендорную библиотеку для конструирования поисковых и фильтрационных запросов. Результаты поиска возвращаются в виде массива объектов сущности или документа Doctrine ORM/ODM, привязанной к поисковому индексу. Подробнее о FOSElasticaBundle, традиционно, на гитхабе: github.com/FriendsOfSymfony/FOSElasticaBundle

Использование бандла позволяет полностью абстрагироваться от манипуляций с чистым JSON, что-то кодировать и декодировать функциями json_encode и json_decode, лезть куда-то с помощью сurl. Здесь только ООП подход!

Немного о схеме данных в SQL

Поскольку мои товары хранятся в реляционной СУБД, мне понадобилось реализовать EAV модель для их свойств и значений (подробнее: en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model )

В результате, у меня вышла вот такая схема данных:
image
Читать дальше →
Total votes 24: ↑24 and ↓0 +24
Views 45K
Comments 22

Быстрый фильтр каталога для интернет-магазинов на основе битмапов Redis

Website development *PHP *NoSQL *


Не секрет, что каждый интернет-магазин должен помогать пользователям найти то, что им нужно. Особенно, если товаров у вас много (> 10). На помощь приходит каталогизация товаров, но разбить товары по категориям — полдела. Товары внутри категории нужно уметь фильтровать по их свойствам. Особенно, если товары у вас разношёрстные, например, одежда, электроника, ювелирные изделия и т.д. И тут любой разработчик, пишущий свой e-commerce продукт, сталкивается с неприятными реалиями жизни: у товаров могут быть совершенно разные свойства, у некоторых товаров они могут отсутствовать, некоторые товары по одному свойству могут попадать под разные значения (цвет платья то ли синий, то ли голубой, соответственно, неплохо бы его показать и по синему и по голубому цвету). Проще говоря, у вас EAV. Бывает ещё, что EAV вам диагностирует заказчик ближе к концу разработки, а то и просит добавить фильтр по динамическим свойствам уже после релиза.
Читать дальше →
Total votes 38: ↑35 and ↓3 +32
Views 58K
Comments 75

Замена EAV на JSONB в PostgreSQL

PostgreSQL *SQL *Data storage *
Translation
TL; DR: JSONB может значительно упростить разработку схемы БД без ущерба производительности в запросах.

Введение


Приведем классический пример, наверное, одного из старейших вариантов использования в мире реляционных БД (база данных): у нас есть сущность, и необходимо сохранить определенные свойства (атрибуты) этой сущности. Но не все экземпляры могут имеют одинаковый набор свойств, к тому же в будущем, возможное добавление ещё свойств.

Самый простой путь решения этой проблемы – это создание столбца в таблице БД для каждого значение свойства, и просто заполнять те, которые нужны для определенного экземпляра сущности. Отлично! Проблема решена… до того момента, пока ваша таблица не содержит миллионы записей и у вас не возникнет необходимость добавить новую запись.

Рассмотрим паттерн EAV (Entity-Attribute-Value), он встречается достаточно часто. Одна таблица содержит сущности (записи), другая таблица содержит имена свойств (атрибутов), а третья таблица связывает сущности с их атрибутами и содержит значение этих атрибутов для текущей сущности. Это дает вам возможность иметь разные наборы свойств для разных объектов, а также добавлять свойства “на лету”, не изменяя структуры БД.
Читать дальше →
Total votes 41: ↑36 and ↓5 +31
Views 15K
Comments 39

Идеальный каталог, базовая библиотека

PHP *System Analysis and Design *SQL *
Recovery mode
✏️ Technotext 2021

Всем привет.

У меня было несколько публикаций по теме Entity Attribute Value, сокращенно EAV (паттерн программирования для хранения произвольных данных). За прошедшее время я допилил библиотеку для работы с EAV, и хотел бы поделиться с вами своими наработками.

В библиотеке реализован базовый сценарий:

Читать далее
Total votes 4: ↑2 and ↓2 0
Views 2.5K
Comments 24

Очередной универсальный интернет каталог средствами реляционной СУБД

PostgreSQL *SQL *Development for e-commerce *
Sandbox

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

Существует множество подходов к реализации таких требований. Это и nosql решения и механизмы работы с json в реляционных СУБД. До nosql эпохи, решать такие задачи приходилось средствами реляционных БД.

Основная причина по которой реляционные СУБД плохо подходят для решения таких задач это разнообразие характеристик товаров. Набор характеристик к примеру для одежды и смартфонов будет совершенно разный. В самом деле не создавать же для каждой категории товаров отдельную таблицу с со своим набором реквизитов.

По этой причине в большинстве случаев в реляционных БД используется EAV (Entity Attribute Value) модель данных в тех или иных вариациях.

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

Есть мнение, что EAV вообще является анти паттерном, что тоже не лишено оснований, однако надо заметить, что есть и другое мнение, что лучше такая схема, чем вообще отсутствие таковой.

Рискуя навлечь на себя гнев сообщества хочу представить свой вариант реализации каталога. Это не совсем EAV, скорее его по мотивам.

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

Всё описанное далее предполагает использование СУБД Postgresql.

Читать далее
Total votes 6: ↑6 and ↓0 +6
Views 4.4K
Comments 8

Идеальный каталог, замеры производительности

PHP *PostgreSQL *SQL *Data storage *

Всем привет.

Я разрабатываю библиотеку для работы с Entity Attribute Value (репозиторий), сокращенно EAV (модель базы данных для хранения произвольных данных). В конце прошлой статьи я спросил у вас о чём мне ещё надо написать, вы попросили показать пример использования и сделать замеры быстродействия.

Что для нас важно при работе с данными ? Скорость записи (добавления или обновления) и скорость чтения (конкретно - фильтрации по моделям одной сущности). При чём скорость поиска в приоритете, потому что записываем мы один раз в цать дней, а читаем каждую минуту/секунду и даже не один раз, а может быть и не одну сотню раз.

Фишка библиотеки в том что бы работать не с представлением построенном на базовых таблицах EAV, а работать с небольшой частью этих данных записанных в отдельное материализованное представление или в отдельную таблицу.

В Новогодние каникулы я сделал замеры производительности и хочу с вами поделиться результатами

Что будем измерять ?

Чтение:

Время вычитывания всех позиций категории

Время формирования параметров фильтрации

Время фильтрации

Запись:

Время добавления новой характеристики (атрибута)

Время добавления новой товарной позиции (модели)

Время обновления товарной позиции

Читать далее
Total votes 10: ↑6 and ↓4 +2
Views 2.3K
Comments 9

Идеальный каталог, пример использования

PHP *PostgreSQL *SQL *Data storage *

Я разрабатываю библиотеку для работы с Entity Attribute Value (репозиторий), сокращенно EAV (структура базы данных для хранения произвольных данных). В конце прошлой статьи я спросил у вас о чём мне ещё надо написать, вы попросили показать пример использования и сделать замеры быстродействия. Про замеры быстродействия статья была, эта будет о примере использования.

Назначение библиотеки

Прежде чем рассказать об использовании, надо обозначить цели этого использования. Первая цель это автоматизировать запись произвольных данных. Вторая цель - читать ранее записанные данные и делать произвольные выборки по этим данным.

Для этих двух целей применяется EAV, но он существенно замедляется при увеличении объёма данных, и главная цель библиотеки это сделать скорость работы с данными независимой от объёма данных.

Это достигается за счёт использования материализованных представлений и таблиц, и главная задача которую решает библиотека, это синхронизации данных между таблицами EAV и конкретными таблицами, выделенными под каждую категорию (Entity - сущность). Конечно сущность может быть выделена в материализованное представление, библиотека оставляет выбор за пользователем.

В статье будут приведены примеры того как задать произвольный набор атрибутов для произвольной сущности и как сделать выборку данных с произвольными условиями.

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

Читать далее
Total votes 13: ↑8 and ↓5 +3
Views 4.7K
Comments 20

SQL HowTo: разные варианты работы с EAV

Тензор corporate blog PostgreSQL *SQL *Database Administration *ERP-systems *

Соблазн использовать модель EAV (Entity-Attribute-Value) при организации структуры БД весьма велик, особенно когда предметная область заранее плохо известна (или разработчик просто не хочет в нее углубляться). Это ведь так удобно - создать "универсальный" способ описания характеристик объектов, который больше не потребует доработок базы ни при появлении новых типов объектов, ни при возникновении новых атрибутов...

Однако, за любую универсальность приходится платить сложностью и производительностью запросов - так что json[b] может оказаться более эффективной заменой. Но если уж такая модификация невозможна - давайте попробуем выжать максимум производительности из доставшегося нам legacy на самом простом примере.

Читать далее
Total votes 24: ↑23 and ↓1 +22
Views 7.3K
Comments 7