DataGrip, там ручками схему построить нельзя, но можно выбрать один из 10+ вариантов, я обычно выбираю Layout => Directed Orthogonal — самая «прямолинейная» схема получается.
промежуточные таблицы учитывать не надо, рабочих таблиц там пять, это если по феншую делать, если не по феншую то 4.
Зачем в голове держать промежуточные? их название очевидны, если я хочу связать item и content, то я использую item_content — это просто дополнительная строчка в запросе.
при выборке что нам надо?
рубрика
позиция
свойство
значение
максимум сюда закидывается иерархия, но всё это фигня, один раз пишем слой доступа к данным и забываем его как страшный сон.
Всякое добавление записей — аналогично, два дня слёз и боли и можно об этом больше не вспоминать и говорить уже на языке бизес логики, потому что когда алфавит и словарь разработаны, уж предложения из них складывать это уже фигня делов.
и как я говорю весь SQL генериться приложением на лету, наше дело написать методы для генерации элементарных кусочков, а они очень простые, реально простые :))
ещё через неделю покажу.
PS
по поводу ES подумал, что у меня его функционал повторяется, но фишка в том что новому прогеру уже знакомому с ES будет легче понять кодовую базу, поэтому таки через какое то время надо будет с моего велосипеда пересесть на ES, хотя… мой велосипед ещё ни разу из «гаража» не выезжал :)
вам кажется, даже когда пишешь запросы в DataGrip нет ни каких проблем с джоинами, пишешь «join item_content ic on » и тут DataGrip сам подставляет нужные поля «ON i.id = ic.item_id» — только успевай что контрол пробел нажимать, а уж всякие Yii2 с пол пинка генерят:
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.
Мой жизненный опыт говорит мне: всё сложности у человека в голове, в жизни всё решаемо.
почему отказалась? этот вопрос чуть чуть за плоскостью статьи, если очень интересно отвечу в личке.
Но в тоже время одна из причин публикации в том что бы послушать критику. Всё что было сказано в коментах к первой части свелось только к тому что иерархические запросы это плохо, собственно архитектуру ни кто не «осудил».
Вот сейчас мне рассказали про ES — уже что то, хотя если оно ищет в рамках только одной таблицы, то не годиться, короче надо посмотреть на практике что оно умеет.
автор предложил, но команда отказалась с таким работать :) поэтому автор с чистой совестью делиться забракованной идей.
по Elastic Search надо в деле попробовать, оно по иерархии умеет искать? в качестве поискового движка наверное можно использовать, но у архитектуры есть ещё и переброска туда сюда, того сего :))) была позиция экскаватором погрузчиком, а стала экскаватором карьерным и всякое такое прочее, типа вычисление средней цены и прочей аналитики.
вообще это вторая часть «повествования», первая была про архитектуру, а как реализовать — PG / MySql или ES дело десятое, просто пример реализации.
эксплэйны зависят от статистики запросов к таблицам и статистики использования индексов и прочих статистик, на тестовой базе из 10-ти записей и с нулём пользователей, толку от таких эксплейнов ноль.
а что там настраивать? или в смысле какие два приложения установить, с какими настройками?
на ру-трекере
спасибо.
Зачем в голове держать промежуточные? их название очевидны, если я хочу связать item и content, то я использую item_content — это просто дополнительная строчка в запросе.
при выборке что нам надо?
максимум сюда закидывается иерархия, но всё это фигня, один раз пишем слой доступа к данным и забываем его как страшный сон.
Всякое добавление записей — аналогично, два дня слёз и боли и можно об этом больше не вспоминать и говорить уже на языке бизес логики, потому что когда алфавит и словарь разработаны, уж предложения из них складывать это уже фигня делов.
и как я говорю весь SQL генериться приложением на лету, наше дело написать методы для генерации элементарных кусочков, а они очень простые, реально простые :))
ещё через неделю покажу.
PS
по поводу ES подумал, что у меня его функционал повторяется, но фишка в том что новому прогеру уже знакомому с ES будет легче понять кодовую базу, поэтому таки через какое то время надо будет с моего велосипеда пересесть на ES, хотя… мой велосипед ещё ни разу из «гаража» не выезжал :)
то есть Gii видит, что business_process связан с business_object через privilege, и в методах можно использовать getBusinessProcesses и даже не знать что оно связано через privilege.
Мой жизненный опыт говорит мне: всё сложности у человека в голове, в жизни всё решаемо.
Но в тоже время одна из причин публикации в том что бы послушать критику. Всё что было сказано в коментах к первой части свелось только к тому что иерархические запросы это плохо, собственно архитектуру ни кто не «осудил».
Вот сейчас мне рассказали про ES — уже что то, хотя если оно ищет в рамках только одной таблицы, то не годиться, короче надо посмотреть на практике что оно умеет.
по Elastic Search надо в деле попробовать, оно по иерархии умеет искать? в качестве поискового движка наверное можно использовать, но у архитектуры есть ещё и переброска туда сюда, того сего :))) была позиция экскаватором погрузчиком, а стала экскаватором карьерным и всякое такое прочее, типа вычисление средней цены и прочей аналитики.
вообще это вторая часть «повествования», первая была про архитектуру, а как реализовать — PG / MySql или ES дело десятое, просто пример реализации.
ЗЫ
ES — это что?