Комментарии 22
эксплэйны зависят от статистики запросов к таблицам и статистики использования индексов и прочих статистик, на тестовой базе из 10-ти записей и с нулём пользователей, толку от таких эксплейнов ноль.
ЗЫ
ES — это что?
ЗЫ
ES — это что?
автор предложил, но команда отказалась с таким работать :) поэтому автор с чистой совестью делиться забракованной идей.
по Elastic Search надо в деле попробовать, оно по иерархии умеет искать? в качестве поискового движка наверное можно использовать, но у архитектуры есть ещё и переброска туда сюда, того сего :))) была позиция экскаватором погрузчиком, а стала экскаватором карьерным и всякое такое прочее, типа вычисление средней цены и прочей аналитики.
вообще это вторая часть «повествования», первая была про архитектуру, а как реализовать — PG / MySql или ES дело десятое, просто пример реализации.
по Elastic Search надо в деле попробовать, оно по иерархии умеет искать? в качестве поискового движка наверное можно использовать, но у архитектуры есть ещё и переброска туда сюда, того сего :))) была позиция экскаватором погрузчиком, а стала экскаватором карьерным и всякое такое прочее, типа вычисление средней цены и прочей аналитики.
вообще это вторая часть «повествования», первая была про архитектуру, а как реализовать — PG / MySql или ES дело десятое, просто пример реализации.
почему отказалась? этот вопрос чуть чуть за плоскостью статьи, если очень интересно отвечу в личке.
Но в тоже время одна из причин публикации в том что бы послушать критику. Всё что было сказано в коментах к первой части свелось только к тому что иерархические запросы это плохо, собственно архитектуру ни кто не «осудил».
Вот сейчас мне рассказали про ES — уже что то, хотя если оно ищет в рамках только одной таблицы, то не годиться, короче надо посмотреть на практике что оно умеет.
Но в тоже время одна из причин публикации в том что бы послушать критику. Всё что было сказано в коментах к первой части свелось только к тому что иерархические запросы это плохо, собственно архитектуру ни кто не «осудил».
Вот сейчас мне рассказали про ES — уже что то, хотя если оно ищет в рамках только одной таблицы, то не годиться, короче надо посмотреть на практике что оно умеет.
простейший фильтр по свойствам товаров типа умеет, осталось тесты провести что быстрее, и что удобней в отладке и профилировании.
вам кажется, даже когда пишешь запросы в DataGrip нет ни каких проблем с джоинами, пишешь «join item_content ic on » и тут DataGrip сам подставляет нужные поля «ON i.id = ic.item_id» — только успевай что контрол пробел нажимать, а уж всякие Yii2 с пол пинка генерят:
то есть Gii видит, что business_process связан с business_object через privilege, и в методах можно использовать getBusinessProcesses и даже не знать что оно связано через privilege.
Мой жизненный опыт говорит мне: всё сложности у человека в голове, в жизни всё решаемо.
backend/models/BusinessObject.php
public function getBusinessProcesses()
{
return $this->hasMany(BusinessProcess::className(), ['id' => 'business_process_id'])->viaTable('privilege', ['business_object_id' => 'id']);
}
то есть Gii видит, что business_process связан с business_object через privilege, и в методах можно использовать getBusinessProcesses и даже не знать что оно связано через privilege.
Мой жизненный опыт говорит мне: всё сложности у человека в голове, в жизни всё решаемо.
Коллега SbWereWolf, впечатлен поисковым SQL'ом в полной мере. Универсальность подразумевает сложность. Вернее даже многоступенчатую связность причин-следствий. "Почему здесь Ж? Вот смотрите: из А следует Б, из Б — В,… а из Ё — Ж!" Принцип "7 плюс-минус 2" описывает кол-во объектов, на которых одновременно может фокусироваться человек. Популярные решения ориентированы на тех, кто "5". А "Ж" — это уже 8. Еще подъемно, но уже не всем. Мне, например, тяжело понять, как работает "общепоисковой SQL", но я восхищен вашей способностью его составить.
промежуточные таблицы учитывать не надо, рабочих таблиц там пять, это если по феншую делать, если не по феншую то 4.
Зачем в голове держать промежуточные? их название очевидны, если я хочу связать item и content, то я использую item_content — это просто дополнительная строчка в запросе.
при выборке что нам надо?
максимум сюда закидывается иерархия, но всё это фигня, один раз пишем слой доступа к данным и забываем его как страшный сон.
Всякое добавление записей — аналогично, два дня слёз и боли и можно об этом больше не вспоминать и говорить уже на языке бизес логики, потому что когда алфавит и словарь разработаны, уж предложения из них складывать это уже фигня делов.
и как я говорю весь SQL генериться приложением на лету, наше дело написать методы для генерации элементарных кусочков, а они очень простые, реально простые :))
ещё через неделю покажу.
PS
по поводу ES подумал, что у меня его функционал повторяется, но фишка в том что новому прогеру уже знакомому с ES будет легче понять кодовую базу, поэтому таки через какое то время надо будет с моего велосипеда пересесть на ES, хотя… мой велосипед ещё ни разу из «гаража» не выезжал :)
Зачем в голове держать промежуточные? их название очевидны, если я хочу связать item и content, то я использую item_content — это просто дополнительная строчка в запросе.
при выборке что нам надо?
- рубрика
- позиция
- свойство
- значение
максимум сюда закидывается иерархия, но всё это фигня, один раз пишем слой доступа к данным и забываем его как страшный сон.
Всякое добавление записей — аналогично, два дня слёз и боли и можно об этом больше не вспоминать и говорить уже на языке бизес логики, потому что когда алфавит и словарь разработаны, уж предложения из них складывать это уже фигня делов.
и как я говорю весь SQL генериться приложением на лету, наше дело написать методы для генерации элементарных кусочков, а они очень простые, реально простые :))
ещё через неделю покажу.
PS
по поводу ES подумал, что у меня его функционал повторяется, но фишка в том что новому прогеру уже знакомому с ES будет легче понять кодовую базу, поэтому таки через какое то время надо будет с моего велосипеда пересесть на ES, хотя… мой велосипед ещё ни разу из «гаража» не выезжал :)
В одной из компаний, где я работал, использовалась собственная реализация чего-то подобного.
В общих чертах можно описать так. Во главе всего идёт метаописание структуры данных. Структура описана в .mdb файле. В этом файле архитектором создаются сущности, свойства (простые, табличные, агрегированные и ещё несколько типов). Был написан специальный инструмент для упрощения редактирования этой метаинформации. Сущности описывались древовидной структурой с наследованием — т.е. от базового объекта были производные объекты, наследующие свойства базовых объектов и добавляющие собственные свойства.
После этого .mdb файлик скармливается специальной софтине, которая отражает эту структуру на реальную БД, создавая хранилище.
К этому всему написан специальный ORM-фреймворк (.Net), реализующий DAL, BE и UI слои.
Фреймворк позволяет выполнять заполнение, редактирование списков объектов, карточек объектов, а также относительно эффективный поиск.
В коде объект отражался на специальный класс с динамическим списком свойств и при необходимости создавались наследники от базового класса с отражением динамических свойств на конкретные геттеры/сеттеры.
Все списки и карточки — универсальные, работающие через метаописание структуры данных. Естественно всё это дело расширяемое и при необходимости можно расширять стандартные списки/карточки для более тонкого редактирования специфических объектов со специфическими свойствами.
В базовом фреймворке уже есть предустановленная структура объектов типа пользователей и других объектов, являющихся базовыми для любого прикладного проекта.
На основании этого фреймворка разрабатывались прикладные проекты, расширяющие базовую структуру данных. У прикладного проекта своя собственная структура данных, которая мёржится с базовой структурой.
Кроме того имеется классификатор, позволяющий просматривать итоговую мета-структуру данных для изучения предметной области.
Помимо всего этого там было накручена тонна рюшечек и компания разрабатывает 5-7 прикладных проектов на базе этого фреймворка.
По поводу производительности всё довольно неплохо, среди прикладных проектов — развитые системы для крупного ритейла, складской софт с адресным хранением, логистика и т.д.
Всех деталей сразу не припомнить и не описать, вся эта штука разрабатывается уже даже не десяток лет но в целом имеет свой шарм, хотя и имеет высокий порог входа — настолько много кода там налопачено.
В общих чертах можно описать так. Во главе всего идёт метаописание структуры данных. Структура описана в .mdb файле. В этом файле архитектором создаются сущности, свойства (простые, табличные, агрегированные и ещё несколько типов). Был написан специальный инструмент для упрощения редактирования этой метаинформации. Сущности описывались древовидной структурой с наследованием — т.е. от базового объекта были производные объекты, наследующие свойства базовых объектов и добавляющие собственные свойства.
После этого .mdb файлик скармливается специальной софтине, которая отражает эту структуру на реальную БД, создавая хранилище.
К этому всему написан специальный ORM-фреймворк (.Net), реализующий DAL, BE и UI слои.
Фреймворк позволяет выполнять заполнение, редактирование списков объектов, карточек объектов, а также относительно эффективный поиск.
В коде объект отражался на специальный класс с динамическим списком свойств и при необходимости создавались наследники от базового класса с отражением динамических свойств на конкретные геттеры/сеттеры.
Все списки и карточки — универсальные, работающие через метаописание структуры данных. Естественно всё это дело расширяемое и при необходимости можно расширять стандартные списки/карточки для более тонкого редактирования специфических объектов со специфическими свойствами.
В базовом фреймворке уже есть предустановленная структура объектов типа пользователей и других объектов, являющихся базовыми для любого прикладного проекта.
На основании этого фреймворка разрабатывались прикладные проекты, расширяющие базовую структуру данных. У прикладного проекта своя собственная структура данных, которая мёржится с базовой структурой.
Кроме того имеется классификатор, позволяющий просматривать итоговую мета-структуру данных для изучения предметной области.
Помимо всего этого там было накручена тонна рюшечек и компания разрабатывает 5-7 прикладных проектов на базе этого фреймворка.
По поводу производительности всё довольно неплохо, среди прикладных проектов — развитые системы для крупного ритейла, складской софт с адресным хранением, логистика и т.д.
Всех деталей сразу не припомнить и не описать, вся эта штука разрабатывается уже даже не десяток лет но в целом имеет свой шарм, хотя и имеет высокий порог входа — настолько много кода там налопачено.
запилить что то типа того моя мечта :))
Реализация сего чуда заняла что-то около года труда 5-10 разрабов, а доведение этой поделки до ума продолжается и по сей день. Если без фанатизма и преждевременного перенасыщения продукта фичами — в принципе может получиться неплохая расширяемая платформа, но в целом нужно иметь конкретную сферу применения в виде развитой линейки прикладных продуктов, иначе овчинка выделки не стоит.
Вы не смотрели на RDF-хранилища и язык запросов SPARQL?
Эта технология для каталогов подходит лучше, чем реляционные базы данных.
Эта технология для каталогов подходит лучше, чем реляционные базы данных.
спасибо за подсказку, будем почитать
Я даже пример набросал: https://habrahabr.ru/post/324012/ :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Идеальный каталог, вариант реализации