работать с такой базой напрямую удобнее чем с кашей из данных в паре таблиц
В библиотеке реализованно ровно то что вы предлагаете. Для каждой сущности создаётся отдельная таблица и колонки в эту таблицу добавляются произвольно, по необходимости.
Шаблонный SQL код по работе с данными (DML) и генерации схемы данных (DDL) спрятан в методы, ни какая ORM не применяется. Библиотека это только proof of concept, мне было интересно посмотреть на сколько трудно будет автоматизировать DDL и какое быстродействие будет в итоге.
Исходники открытые, запрета на изменение и применение нет, код можно крутить куда и сколько хочется. Сделать любые оптимизации, любые изменения в алгоритмах.
В итоге как оказалось, генерация DDL это совсем не трудно, и то что получилось работает достаточно быстро. Я не вижу разницы по быстродейтсвию между работой с таблицей сгенерировнной библиотекой и таблицей сгенерированной "миграцией". Если разница и есть, то она не заметна на фоне того сколько времени СУБД выполняет запрос к данным. Плюс минус миллесекунда не имеет значения, когда у нас сами данные вычитываются 20-40 мс.
Посмотрел бы я что вам ДБА ответит если вы предложите в рантайме по запросу пользователя менять схему БД
Почему бы и нет, если вести работу с товарным каталогом в отдельном загончике - отдельной БД. Тем более, что схема БД меняется не так часто и не любым пользователем. Состав характеристик товара меняется только при поступлении "новой коллекции", даже не каждый месяц.
Мне кажется для большинства проектов в интернете, для товарного каталога, достаточно Битрикса или Magento / OpenCart.
Потому что Битрикс тоже умеет хранить категорию в отдельной таблице, конечно это делается через цать дополнительных запросов, и у Битрикса это не так быстро как в случае библиотеки "Универсальный каталог", но не на столько что бы отказываться от админки и другой инфраструктуры которую предлагает Битрикс.
Я на днях пытался придумать где бы могла пригодиться эта библиотека - "Универсальный каталог" и особо не придумал. Возможно для каких то уникальных проектов, которым не нужна интеграция с бухгалтерией. Или там где людям нужно работать с произвольными данными, но лень заморачиваться на Битрикс.
Отказ от фильтрации на стороне СУБД это очень смелый шаг.
Для фильтрации средствами приложения вы должны всё выгрузить из СУБД в память приложения и дальше без каких либо индексов, делать выборку.
Я не знаю .. in-memory СУБД тогда уж применяйте, если вам оперативной памяти не жалко. Тарантул например.
Почитайте о jsonb, посмотрите доклад Олега Бартунова с последнего хайлрада, в постгресе очень сильно поработали над jsonb, это очень сильный инструмент.
По полям внутри json можно построить индекс, выборка производиться при использовании этого индекса. К полям внутри json можно применять такие же операции сравнения как к обычным колонкам.
Вам только придётся научиться со всем этим работать. Но оно того стоит.
Если вам интересна идея моей библиотеки, то у меня в профиле посмотрите другие статьи по "Универсальному каталогу". Мне кажется я очень подробно описал идею.
Вы, простите, статью читали ? С помощью моей библиотеки это будет запрос к колонкам одной таблицы или одного материализованного представления.
Запросы делаются не на основе мастер данных в eav таблицах, запросы делаем к предварительно сформированным материализованному представлению или таблице.
У меня в бенчмарке замеряется выборка по 46 колонкам для первого случая, об этом написано в статье.
Для второго случая 14, для третьего 2. Хотел это добавить в статью, но редактор выдаёт 400 ошибку. Пришлось оставить как есть.
Jsonb не может дать такие же эффективные запросы, потому что это запросы к упакованным в одну колону данным, а не к отдельным колонкам, как в моей библиотеке. Будет или так же или медленей.
У вас было 600к значений, на моём наборе данных их 800к+600к = 1,4кк. У вас 50к моделей, у меня всего 29к, но разница в два раза для таких значений уже несущественна.
Если выборка идёт за десятые доли секунды, то это сотни миллисекунды, у меня в измерениях максимум десятки миллесекунд, то есть работа с таблицей выигрывает у работы с jsonb на порядок.
Но конечно для работы с jsonb не надо такой огород городить как у меня, но с другой стороны, когда кто то уже сделал инструмент, почему бы и нет ?
Попробую написать бенчмарк для jsonb, спасибо за идею.
XMLReader работает на очень низком уровне, буквально лексический разбор.
В одной из первых иттераций парсинга, была мысли результат $reader->read() отдавать последователь во все парсеры и таким образом документ бы парсился за один проход.
Но когда другие команды стали писать свои парсеры, они эту идею не оценили, пришлось один и тоот же докумнет передавать в кучу парсеров.
Для XML, в котором вас интересует больше 10-ти элементов, на код страшно смотреть, либо если всё завернуть в приватные методы, то получается слишком много микроскопических методов с шабонным кодом, хотя эту проблему тоже можно решить, но всё равно на выходне много букв, устаёшь скролить и читать.
Почему я стал искать альтернативу XMLReader ? Все входящие сообщения у нас парсились на примерно 10-ке парсерах, и вот один из парсеров выполнялся по 2 секунды, при том что этот парсер не находил ни чего для себя интересного, то есть работал в холостую, другие аналогичные парсеры отрабатывали документы за 5-50 мс максимум.
По идее этот неудачный парсер за каждый цикл чтения $reader->read() выполнял около 20-ти раз оператор IF, ине понятно чему там тормозить, когда я переписал его на SimpleXMLElement , время работы сократилось до приемлимых 50мс.
Как мне кажестя SimpleXMLElement не вычитывает весь документ за раз и не строит DOM, SimpleXMLElement вычитывает один элемент (все атрибуты и "иннер текст") за раз и строит только его объектную модель.
Если бы оно выжирало гигабайты памяти (какие то XML у нас реально гигабайты весят), мне бы настучали по голове и по рукам, но этого не произошло: или этого ни разу не было, или админы не успели заметить :)
Сейчас после последней оптимизации на каждый документ вызывается парсер соответствующий его пространству имён. Поэтому сейчас на каждый документ не создаётся по 10+ джоб, создаётся одна или не одной.
Но осадочек остался, с SimpleXMLElement код очень приятно писать, снова чувствуешь себя человеком, а не студентом второго курса пишущем на ассембелере.
Если у бизнес команд горит и им не когда ждать, что бы им написали парсер, то было решено отдавать массив (с помощью Converter).
Кроме того, разным командам в одном и том же документе могут быть интересны разные куски, что бы не заморачиваться, поэтому мы решили всегда отдавать массивом, когда парсинг станет слишком прожорливым - придумаем что ни будь ещё.
Позже я написал объектно ориентированную обёртку над этим массивом (XmlNavigator).
Такая история есл икоротко, и промолчать пр о100500 нюансов.
Я написал что пользуюсь разными инструментами, в том числе и XMLReader , и SimpleXMLElement, судя по опросу многие делают так же, это называется не разобраться в теме ?
Вы знаете почему надо из документа сделать DTO и отдать на обработку дальше, другой команде ?
Вы знаете что другая команда отказывается иметь дело с XML и ждёт от вас только DTO, максимум на что согласны - на массив ?
Вы знаете что документ который надо распарсить имеет не тривиальную XSD, и уникальных элементов в нём до 300 ?
Времени на задачу у вас два дня от силы. Ваши действия ?
Вы разобрались в теме или и так соёдёт ?
Я не знаю каких в вашей жизни причин нет, а в моей жизни причин хватает :)
соц сеть предоставляет платформу, как провайдер предоставляет машину в ЦОДе, точно так же и соц сеть предоставляет механизм, то как его будет использовать, во благо, во вред, по закону, с нарушением, это дело пользователя, соц сеть за это не отвечает.
вам нож продали, вы им угрожали во время ограбления, магазин который вам продал нож виноват ? завод который нож произвёл виноват ?
что нож, что платформа, что виртуалка в ЦОДе - это только инструмент
Для переводов очевидно использовать json, нет ? Или mysql не умеет json колонки ?
Или переводы на каждый язык это всё равно отдельная запись HL-блока ?
Второе забавное. На колонку можно навешать своё правило сортировки (например считать что "е" и "ё" равны, или считать, что "е" меньше "ё"). В postgre, я думаю так и сделано. Но когда вы все переводы переносите в одну колонку, в этот момент вы теряете возможность сортировки строк с учетом языковых особенностей.
С другой стороны сортировка по названию наверное не принципиальна.
И последний вопрос, правильная архитектура в контексте Битрикса ?
публикуется от имени кого ? в СМИ от имени СМИ и под ответственность СМИ, в соц сети от имени пользователя и под ответственность пользователя.
Хотите что бы соц сети от имени соц сети и под ответственность соц сети ? тогда премодерация должна быть. Хотите ? сделайте такую соц сеть и закончим этот разговор.
не надо из соц сети делать СМИ. Потому что это не средство массовой информации, соц сеть не распространяет информацию, соц сеть распространяет эмоции и нужна для эмоций.
Это частное личное мнение и оно может быть любым, человек имеет право на мнение. Пишите свои мнения, ваше право.
перед публикацией в СМИ любые рекламные материалы проходят модерацию.
Так же как и реклама на интернет площадках, и вот там соц сети, да и любые другие распрастранители рекламы делаю премодерацию. нет там свободной публикации чего угодно.
СМИ сами контент генерят. а соц сеть свой контент не генерит, она его только размещает, СМИ это источник, а соц сеть это только площадка, это стена на которой может любой дурак написать.
И этих дураков должна полиция ловить, а соц сеть может только по решению суда какие то надписи закрасить, или исходя из собственного разумения, как владелец стены, имеют право решать что на ней будет написано, а что не будет.
Вот в чём разница между соц сетью и СМИ, соц сеть это стены, а СМИ это буквы на стене. Буквы отвечают за своё содержание, а стена отвечает только за цвет фона и целостность штукатурки
Соц сеть не обязана фильтровать контент. Если я хожу в бар и устраиваю дебошь то это не обязаность бара скрутить меня в бараний рог. Это обязанность правоохранительных органов по заявлению пострадавших или свидетелей. Так же и с соц сетями. Соц сеть это площадка для публикаций. Если публикация нарушает закон, то должен быть пострадавшмй и должна быть правовая оценка со стороны прокуратуры. Точка. Сам сервис не обязан цензуру вести. А если ведет, то качество цензуры на усмотрение сервиса, а ее пользователей.
Если пользователь считает что сайт нарушает его права, то свои права пользователь защищает в суде.
я к тому что этот же архив на который вы дали ссылку, можно закинуть на гит-хаб как репозиторий и в статье разместить ссылку на репозиторий, а не на скачивание архива.
На мой вкус пустую строку можно на вход получить, её надо интерпретировать как 0.
Валидацию на не цифровые символы я бы сделал регулярным выражением.
И конечно в эксепшенах надо давать намёк на причину ошибки, лучше давать подсказки о том как ошибку исправить.
Так или не так, проверяется юнит тестами.
На PHP это делается одной командой :)) Поэтому к этому тестовому надо давать комментарий о том что требуется решить через алгоритм сложения в столбик, то есть с контролем переполнения десятичной позиции.
В библиотеке реализованно ровно то что вы предлагаете. Для каждой сущности создаётся отдельная таблица и колонки в эту таблицу добавляются произвольно, по необходимости.
Шаблонный SQL код по работе с данными (DML) и генерации схемы данных (DDL) спрятан в методы, ни какая ORM не применяется. Библиотека это только proof of concept, мне было интересно посмотреть на сколько трудно будет автоматизировать DDL и какое быстродействие будет в итоге.
Исходники открытые, запрета на изменение и применение нет, код можно крутить куда и сколько хочется. Сделать любые оптимизации, любые изменения в алгоритмах.
В итоге как оказалось, генерация DDL это совсем не трудно, и то что получилось работает достаточно быстро. Я не вижу разницы по быстродейтсвию между работой с таблицей сгенерировнной библиотекой и таблицей сгенерированной "миграцией". Если разница и есть, то она не заметна на фоне того сколько времени СУБД выполняет запрос к данным. Плюс минус миллесекунда не имеет значения, когда у нас сами данные вычитываются 20-40 мс.
Почему бы и нет, если вести работу с товарным каталогом в отдельном загончике - отдельной БД. Тем более, что схема БД меняется не так часто и не любым пользователем. Состав характеристик товара меняется только при поступлении "новой коллекции", даже не каждый месяц.
Мне кажется для большинства проектов в интернете, для товарного каталога, достаточно Битрикса или Magento / OpenCart.
Потому что Битрикс тоже умеет хранить категорию в отдельной таблице, конечно это делается через цать дополнительных запросов, и у Битрикса это не так быстро как в случае библиотеки "Универсальный каталог", но не на столько что бы отказываться от админки и другой инфраструктуры которую предлагает Битрикс.
Я на днях пытался придумать где бы могла пригодиться эта библиотека - "Универсальный каталог" и особо не придумал. Возможно для каких то уникальных проектов, которым не нужна интеграция с бухгалтерией. Или там где людям нужно работать с произвольными данными, но лень заморачиваться на Битрикс.
Отказ от фильтрации на стороне СУБД это очень смелый шаг.
Для фильтрации средствами приложения вы должны всё выгрузить из СУБД в память приложения и дальше без каких либо индексов, делать выборку.
Я не знаю .. in-memory СУБД тогда уж применяйте, если вам оперативной памяти не жалко. Тарантул например.
Почитайте о jsonb, посмотрите доклад Олега Бартунова с последнего хайлрада, в постгресе очень сильно поработали над jsonb, это очень сильный инструмент.
По полям внутри json можно построить индекс, выборка производиться при использовании этого индекса. К полям внутри json можно применять такие же операции сравнения как к обычным колонкам.
Вам только придётся научиться со всем этим работать. Но оно того стоит.
Если вам интересна идея моей библиотеки, то у меня в профиле посмотрите другие статьи по "Универсальному каталогу". Мне кажется я очень подробно описал идею.
Следующая статья будет с примером использования.
Вы, простите, статью читали ? С помощью моей библиотеки это будет запрос к колонкам одной таблицы или одного материализованного представления.
Запросы делаются не на основе мастер данных в eav таблицах, запросы делаем к предварительно сформированным материализованному представлению или таблице.
У меня в бенчмарке замеряется выборка по 46 колонкам для первого случая, об этом написано в статье.
Для второго случая 14, для третьего 2. Хотел это добавить в статью, но редактор выдаёт 400 ошибку. Пришлось оставить как есть.
Jsonb не может дать такие же эффективные запросы, потому что это запросы к упакованным в одну колону данным, а не к отдельным колонкам, как в моей библиотеке. Будет или так же или медленей.
Да, jsonb это убойная фича Постгреса.
У вас было 600к значений, на моём наборе данных их 800к+600к = 1,4кк. У вас 50к моделей, у меня всего 29к, но разница в два раза для таких значений уже несущественна.
Если выборка идёт за десятые доли секунды, то это сотни миллисекунды, у меня в измерениях максимум десятки миллесекунд, то есть работа с таблицей выигрывает у работы с jsonb на порядок.
Но конечно для работы с jsonb не надо такой огород городить как у меня, но с другой стороны, когда кто то уже сделал инструмент, почему бы и нет ?
Попробую написать бенчмарк для jsonb, спасибо за идею.
XMLReader работает на очень низком уровне, буквально лексический разбор.
В одной из первых иттераций парсинга, была мысли результат $reader->read() отдавать последователь во все парсеры и таким образом документ бы парсился за один проход.
Но когда другие команды стали писать свои парсеры, они эту идею не оценили, пришлось один и тоот же докумнет передавать в кучу парсеров.
Для XML, в котором вас интересует больше 10-ти элементов, на код страшно смотреть, либо если всё завернуть в приватные методы, то получается слишком много микроскопических методов с шабонным кодом, хотя эту проблему тоже можно решить, но всё равно на выходне много букв, устаёшь скролить и читать.
Почему я стал искать альтернативу XMLReader ? Все входящие сообщения у нас парсились на примерно 10-ке парсерах, и вот один из парсеров выполнялся по 2 секунды, при том что этот парсер не находил ни чего для себя интересного, то есть работал в холостую, другие аналогичные парсеры отрабатывали документы за 5-50 мс максимум.
По идее этот неудачный парсер за каждый цикл чтения $reader->read() выполнял около 20-ти раз оператор IF, ине понятно чему там тормозить, когда я переписал его на SimpleXMLElement , время работы сократилось до приемлимых 50мс.
Как мне кажестя SimpleXMLElement не вычитывает весь документ за раз и не строит DOM, SimpleXMLElement вычитывает один элемент (все атрибуты и "иннер текст") за раз и строит только его объектную модель.
Если бы оно выжирало гигабайты памяти (какие то XML у нас реально гигабайты весят), мне бы настучали по голове и по рукам, но этого не произошло: или этого ни разу не было, или админы не успели заметить :)
Сейчас после последней оптимизации на каждый документ вызывается парсер соответствующий его пространству имён. Поэтому сейчас на каждый документ не создаётся по 10+ джоб, создаётся одна или не одной.
Но осадочек остался, с SimpleXMLElement код очень приятно писать, снова чувствуешь себя человеком, а не студентом второго курса пишущем на ассембелере.
Если у бизнес команд горит и им не когда ждать, что бы им написали парсер, то было решено отдавать массив (с помощью Converter).
Кроме того, разным командам в одном и том же документе могут быть интересны разные куски, что бы не заморачиваться, поэтому мы решили всегда отдавать массивом, когда парсинг станет слишком прожорливым - придумаем что ни будь ещё.
Позже я написал объектно ориентированную обёртку над этим массивом (XmlNavigator).
Такая история есл икоротко, и промолчать пр о100500 нюансов.
Очень смешно читать такие коменты.
Я написал что пользуюсь разными инструментами, в том числе и XMLReader , и SimpleXMLElement, судя по опросу многие делают так же, это называется не разобраться в теме ?
Вы знаете почему надо из документа сделать DTO и отдать на обработку дальше, другой команде ?
Вы знаете что другая команда отказывается иметь дело с XML и ждёт от вас только DTO, максимум на что согласны - на массив ?
Вы знаете что документ который надо распарсить имеет не тривиальную XSD, и уникальных элементов в нём до 300 ?
Времени на задачу у вас два дня от силы. Ваши действия ?
Вы разобрались в теме или и так соёдёт ?
Я не знаю каких в вашей жизни причин нет, а в моей жизни причин хватает :)
соц сеть предоставляет платформу, как провайдер предоставляет машину в ЦОДе, точно так же и соц сеть предоставляет механизм, то как его будет использовать, во благо, во вред, по закону, с нарушением, это дело пользователя, соц сеть за это не отвечает.
вам нож продали, вы им угрожали во время ограбления, магазин который вам продал нож виноват ? завод который нож произвёл виноват ?
что нож, что платформа, что виртуалка в ЦОДе - это только инструмент
Для переводов очевидно использовать json, нет ? Или mysql не умеет json колонки ?
Или переводы на каждый язык это всё равно отдельная запись HL-блока ?
Второе забавное. На колонку можно навешать своё правило сортировки (например считать что "е" и "ё" равны, или считать, что "е" меньше "ё"). В postgre, я думаю так и сделано. Но когда вы все переводы переносите в одну колонку, в этот момент вы теряете возможность сортировки строк с учетом языковых особенностей.
С другой стороны сортировка по названию наверное не принципиальна.
И последний вопрос, правильная архитектура в контексте Битрикса ?
публикуется от имени кого ? в СМИ от имени СМИ и под ответственность СМИ, в соц сети от имени пользователя и под ответственность пользователя.
Хотите что бы соц сети от имени соц сети и под ответственность соц сети ? тогда премодерация должна быть. Хотите ? сделайте такую соц сеть и закончим этот разговор.
не надо из соц сети делать СМИ. Потому что это не средство массовой информации, соц сеть не распространяет информацию, соц сеть распространяет эмоции и нужна для эмоций.
Это частное личное мнение и оно может быть любым, человек имеет право на мнение. Пишите свои мнения, ваше право.
перед публикацией в СМИ любые рекламные материалы проходят модерацию.
Так же как и реклама на интернет площадках, и вот там соц сети, да и любые другие распрастранители рекламы делаю премодерацию. нет там свободной публикации чего угодно.
СМИ сами контент генерят. а соц сеть свой контент не генерит, она его только размещает, СМИ это источник, а соц сеть это только площадка, это стена на которой может любой дурак написать.
И этих дураков должна полиция ловить, а соц сеть может только по решению суда какие то надписи закрасить, или исходя из собственного разумения, как владелец стены, имеют право решать что на ней будет написано, а что не будет.
Вот в чём разница между соц сетью и СМИ, соц сеть это стены, а СМИ это буквы на стене. Буквы отвечают за своё содержание, а стена отвечает только за цвет фона и целостность штукатурки
Спасибо, узнал много нового
Соц сеть не обязана фильтровать контент. Если я хожу в бар и устраиваю дебошь то это не обязаность бара скрутить меня в бараний рог. Это обязанность правоохранительных органов по заявлению пострадавших или свидетелей. Так же и с соц сетями. Соц сеть это площадка для публикаций. Если публикация нарушает закон, то должен быть пострадавшмй и должна быть правовая оценка со стороны прокуратуры. Точка. Сам сервис не обязан цензуру вести. А если ведет, то качество цензуры на усмотрение сервиса, а ее пользователей.
Если пользователь считает что сайт нарушает его права, то свои права пользователь защищает в суде.
"Кажется на Хабре следует осторожно обсуждать политику и не критиковать Илона Маска"
Кадется на Хабре не любят кремлеботов, или просто не любят наглую ложь.
я к тому что этот же архив на который вы дали ссылку, можно закинуть на гит-хаб как репозиторий и в статье разместить ссылку на репозиторий, а не на скачивание архива.
Автор спасибо за статью. Можно код на git hub выложить ?
На мой вкус пустую строку можно на вход получить, её надо интерпретировать как 0.
Валидацию на не цифровые символы я бы сделал регулярным выражением.
И конечно в эксепшенах надо давать намёк на причину ошибки, лучше давать подсказки о том как ошибку исправить.
Так или не так, проверяется юнит тестами.
На PHP это делается одной командой :)) Поэтому к этому тестовому надо давать комментарий о том что требуется решить через алгоритм сложения в столбик, то есть с контролем переполнения десятичной позиции.
"Папки больше не пытаются рендериться с иконками, которые показывают превью содержимого папок. Это извращение времён Vista уже забыто."
На самом деле иногда это удобно.
да, август 2021 последний месяц когда будут выходить обновления.