На сайте Xdebug-а есть страничка которая помогает выбрать правильную версию библиотеки под именно вашу версию PHP.
Для этого надо на следовать инструкциям на страничке https://xdebug.org/wizard (Installation Wizard), надо вставить в текстовое поле вывод функции phpinfo().
После того как вывод функции будет проанализирован, на странице появиться ссылка на скачивание файла библиотеки и строки для добавления в php.ini (для конфигурирования PHP).
В статье приведен длинный список для конфига PHP (для php.ini), но к ним нет ни каких пояснений.
Автор, @numbrCodeHbr, добавь пожалуйста описание опцийи обоснования для выбранных значений. Тупо копипаст делать, это не круто.
Нет, не надо понимать, надо уметь работать с чёрными ящиками, какая разница из СУБД получаем данные или данные нам вернёт метод какого то класса ?
Если нам надо что то спроектировать, тогда, да, в таком случае надо понимать в вопросе, а если уже спроектирована БД ? нам просто надо настроить работу приложения с ней, зачем нам вникать ?
Сделали описание структуры для ОРМ, и пользуемся ОРМом, возможно это описание уже кто то сделал.
Это называется специализация, кто то СУБД проектирует, кто то АПИ пишет, кто то формочки рисует..
Статья о том что можно с использованием библиотеки автоматически менять схему и обновлять данные, а не о том как можно решить задачу хранения произвольного набора данных.
Но это же не так. EAV берет на себя задачу по фиксации и контролю за схемой. JSONB этого не позволяет делать.
EAV это способ записи и чтения данных, это не способ контроля целостности, если у сущности 10 атрибутов, а мы создали значения только для пяти, EAV это примет и не выкинет исключения.
Только если мы попытаемся добавить значения для атрибута который не был создан, только тогда у нас будет ошибка. Но и её легко не допустить, если проверять существование атрибута, перед записью, с применением кеша это незначительно утяжелит запрос.
Общее у них только то, что оба позволяют менять схему данных не изменяя, собственно, схему БД.
Как раз моя библиотека и предназначена для того что бы налету менять схему данных. Она делает это прозрачно для клиентской логики. И это будет местом для тюнинга и оптимизаций. Сейчас например при добавлении нового атрибута, таблица целиком пересоздаётся, вместо добавления одно колонки.
JSONB это другой способ решения той же задачи которую решает EAV.
Чисто теоретически, решение через хранение данных в индивидуальных таблицах должно быть быстрее хранения через JSONB. Просто потому что JSONB это куча мала, а таблица это уже распарсенные записи.
По быстродействию в лучшем случаем будет одинаково, а по объёму JSONB больше места занимает, нам надо хранить и сам JSONB и распасенный вариант.
Если вам это интересно, то мы можем вместе написать код и провести замеры.
Вы заблуждаетесь на счёт EAV, посмотрите замеры в статье «Идеальный каталог, оптимизация выборки данных», ссылки по тексту есть.
Когда мы из EAV делаем таблицу или материализованное представление, то поиск по ним ни как не может быть медленней JSONB.
И главная задача этой библиотеки это создание инфраструктуры для работы с EAV через индивидуальную таблицу для данных которые часто обновляются или для работы через материализованное представление для данных которые обновляются крайне редко.
JSONB затащили в постгрес что бы утереть нос MongoDB и прочим. Почему стали популярны документарные БД? потому что не надо заморачиваться на работу со схемой базы данных, во первых это же надо кроме языка программирования научиться разбираться с DDL, что то понимать в СУБД. Второе надо написать библиотечку для работы с EAV и по пути собрать море граблей.
Правильно что ни кто не это не заморачивается, для стартапов это не нужный риск.
А если ты пишешь код для себя, исключительно из академического интереса, то почему бы и нет.
Мне было интересно проверить концепцию, я её проверил и сделал это ещё три года назад в 2018 году когда написал статью «Идеальный каталог, оптимизация выборки данных».
Разработка библиотеки это ещё одно доказательство в пользу жизнеспособности идеи.
И я думаю что эта идея была реализован и не раз, просто в инхаус системах, поэтому широкой публике не известна.
Всему своё место и время. Если джуну в его коде надо что то из базы прочитать, то зачем отвлекать на написание этого кусочка программиста СУБД ?
Разработка это прежде всего производство и чем ниже требования к квалификации тем больше сотрудников можно привлеч к этому производству. Любые библиотеки снижающие требования к квалификации помогаю производству.
Ни кто не запрещает пользоваться сырыми запросами через эту библиотеку или любую другую.
Вы свободны в своём выборе. Вам дают инструмент, а вы можете им не пользоваться, кто то другойосвоиться с ним и ему это будет полезным.
Кворум на общем собрании это 50% и один голос, а не 51%. По каким то вопросам надо 50% ЗА, по другим две трети ЗА, В законах множество нюансов, суду потом не докажешь что приложение так посчитало или что приложение по другому не умеет, суд по букве закона рассудит. Статья относительно Жилищного кодекса очень поверхностная.
Этот код легко масштабируется, меняется, поддерживается и дополняется не только теми, кто его писал, но и любыми другими разработчиками.
Вы сами в это верите? код будет написан под ваш бизнес, но вероятность того что он будет ЛЕГКО масштабироваться и меняться близка к нулю.
Писать код так что бы он легко менялся и масштабировался надо уметь, дело не в том что бы писать под бизнес, дело в том что бы уметь так писать и не лениться так делать.
Сколько живу — ни разу не видел. У Яндексов спросите сколько раз они переписывали свои приложения и сколько там легаси, кода унаследованного и в котором ни кто ни когда не будет разбираться, который при необходимости — заменят другим, но ни когда не будет в нём разбираться.
я про Фому, вы про Ерёму. Главное назначение миграции это возможность как накатить так и откатить изменения в схеме БД без участия человека, в ручном режиме. Сделать эти изменения повторяемыми, не зависящими от среды.
Continuos delivery, миграции, репозитории нужны для переносимости кода, для отчуждаемости кода от разработчика.
Миграция которая создаёт колонку, почему она не должна упасть если в таблице присутствуют какие то другие колонки? Кажется я повторяюсь.
Ваше возмущение по поводу владельцев кода, это что то с чем то. Вас не возмущает что работу между сотрудниками делят по отделам? что каждая команда отвечает за свой функционал или фичу? нет? странно.
Сервис ориентированная архитектура не слышали? Каждый микро-сервис со своим стеком технологий? нет?
Владелец продукта?
У кода не может быть владельца? у Фичи?
чуть чуть страшно за данные, если все таблицы внутри одной бд, то при сбое механизма префиксов, могу быть проблемы с чтением не из той таблицы.
Кроме того, у нас сейчас работа ведётся одновременно в 30-ти ветках, то есть одной таблицы будет 30-ть копий, влитые ветки в мастер ни кто не удаляет, то есть у нас на текущий момент могло бы быть 1800 версий одной и той же таблицы.
Вы в курсе что такое миграции и как они работают? Если миграция создает колонку в таблице, то она упадет только если такая колонка уже создана. Ни один механизм миграцийни когда не проверяет что схема бд находиться в каком то преопределенном состоянии.
Миграции это способ версионировать схему базы данных. Каждая миграция это аналог камита. Каждая миграция это изменение состояния между до миграции и после миграции. Но в отличии от версионирования у миграцийнет дерева. Нет механизма для записи осередности применения измененийк схеме базы данных.
В одной версии эта колонка обязательная (тестируем новый функционал), а в другой эта колонка не обязательная (старые требования), у нас нет возможности развернуть отдельную бд под каждую версию приложения.
На уровне БД если эти проверки делать, то потребуется для каждой версии кода, делать свою версию бд, свои инстанс.
Не айс.
И почему умрёт миграция по добавлению колонок? оно колонки добавит. А вот когда мы будем инсертить через модель новую запись у которой не все колонки заполнены (текущая версия не знает о колонке добавленной другой версией), тогда приложение упадёт.
Система разделена на модули-сервисы, у каждой таблицы есть команда владелец.
Проблема не в том что таблицу правит два разных человека которые между собой не договариваются, проблема в том что для одной фичи нужны одни колонки, для другой другие, и какие то колонки могут после проверки гипотезы на драфте умереть на всегда.
А приложение не должно падать от таких вещей. Если приложению важно что бы какие то данные соответствовали каким то требованиям, то эти требования надо проверять на уровне приложения, а не БД, потому что БД одна, а версий приложения с десяток.
Перекраивать БД под каждую конкретную версию кода не реально (ветки фич иногда приходиться сливать в одну ветку и тестировать их совместную работу)
Мне кажется у вас не было опыта подобной разработки, поэтому вам сложно уловить на слух, это та вещи которую надо увидеть.
Люди из-за проблем с миграциями и деплоем кода в целом, запариваются за переход на сервисную модель, а потом и на микросервисы.
Есть разница между пет проектами, ин-хаус для фирмы на пару тысяч сотрудников и для приложения которое работает с десятками тысяч пользователей с функционалом объёма примерно обычной CRM системы, в которой лидов 100500 вариантов и каждый вариант обрабатывается уникальным образом.
Размер колонок меняется миграцией в любую сторону. Разве это проблема?
Но на самом дела колонки всегда надо создавать максимальной длины. Современным СУБД не важно колонка 10 символов или 100, если в неё пишется только 5, то места на диске будет занято только на 5 символов.
При желании тип колонки можно поменять в миграции. Если колонку добавили недавно, то это не проблема. Если колонку добавили давно, то просто добавляем новую колонку и работаем только с ней, старую колонку не пишем и не читаем.
Работать с таблицами через select *, это всегда был дурной тон. Всегда надо указывать колонки которые вас действительно интересуют.
И на самом деле в таблице должны быть колонки для индексов и одна колонка data в которую пишется json с бизнес данными. Но это высший пилотаж. Для тех кто понимает что такое база данных.
Если в таблице стало 200+ колонок и используется только 10. То почему не начать работать с новой таблицей?
Первый релиз делаем миграцию с новой таблицей и пишем посев данных с переносом данных из одной таблицы в другую, следующий релиз меняем в моделе имя таблицы и теперь мы работаем с новой таблицей в которой только нужные нам 10 колонок.
Люди всегда успешны в достижении своих целей. Это аксиома. Почему кто то решил что целью властей является всеобщее благоденствие?
Их цель удовлетворение собственных аппетитов и ни чего более.
И если вы хотите что бы они заботились о вас, то вам надо сделать так что бы удовлетворение их аппетитов зависело от вашего благосостояния.
Предложение классное, лучше чем текущая реализация md, в части списков и заголовков, но таблицы видимо, да, что не придумывай норм не получиться.
Мне кажется их можно только самые простые делать в простом формате, хотите красоты — пользуйтесь не простыми форматами, используйте для этого навороченные редакторы.
С ручным выравниванием колонок я тоже намучался.
С другой стороны если будет возможность вставить картинку, то проще таблицу нарисовать в продвинутом редакторе и в документ вставить ссылку на картинку.
По части «Преформатированный текст», не соглашусь, писать ```php или ```sql не напрягает, 4 пробела подряд — очень спорное решение. Я понимаю что спец символов доступных из русской раскладки, не так много, но. Почему бы не сделать тройной символ;
С другой стороны что бы написать php всё равно надо раскладку переключить поэтому и символ ` тоже норм. Можно конечно вместо php писать «пхп», «скл», «иксмл», что бы не переключать раскладу, но мне кажется это будет слишком для консервативных умов.
На сайте Xdebug-а есть страничка которая помогает выбрать правильную версию библиотеки под именно вашу версию PHP.
Для этого надо на следовать инструкциям на страничке https://xdebug.org/wizard (Installation Wizard), надо вставить в текстовое поле вывод функции phpinfo().
После того как вывод функции будет проанализирован, на странице появиться ссылка на скачивание файла библиотеки и строки для добавления в php.ini (для конфигурирования PHP).
В статье приведен длинный список для конфига PHP (для php.ini), но к ним нет ни каких пояснений.
Автор, @numbrCodeHbr, добавь пожалуйста описание опцийи обоснования для выбранных значений. Тупо копипаст делать, это не круто.
Нет, не надо понимать, надо уметь работать с чёрными ящиками, какая разница из СУБД получаем данные или данные нам вернёт метод какого то класса ?
Если нам надо что то спроектировать, тогда, да, в таком случае надо понимать в вопросе, а если уже спроектирована БД ? нам просто надо настроить работу приложения с ней, зачем нам вникать ?
Сделали описание структуры для ОРМ, и пользуемся ОРМом, возможно это описание уже кто то сделал.
Это называется специализация, кто то СУБД проектирует, кто то АПИ пишет, кто то формочки рисует..
EAV это способ записи и чтения данных, это не способ контроля целостности, если у сущности 10 атрибутов, а мы создали значения только для пяти, EAV это примет и не выкинет исключения.
Только если мы попытаемся добавить значения для атрибута который не был создан, только тогда у нас будет ошибка. Но и её легко не допустить, если проверять существование атрибута, перед записью, с применением кеша это незначительно утяжелит запрос.
Как раз моя библиотека и предназначена для того что бы налету менять схему данных. Она делает это прозрачно для клиентской логики. И это будет местом для тюнинга и оптимизаций. Сейчас например при добавлении нового атрибута, таблица целиком пересоздаётся, вместо добавления одно колонки.
Чисто теоретически, решение через хранение данных в индивидуальных таблицах должно быть быстрее хранения через JSONB. Просто потому что JSONB это куча мала, а таблица это уже распарсенные записи.
По быстродействию в лучшем случаем будет одинаково, а по объёму JSONB больше места занимает, нам надо хранить и сам JSONB и распасенный вариант.
Если вам это интересно, то мы можем вместе написать код и провести замеры.
Когда мы из EAV делаем таблицу или материализованное представление, то поиск по ним ни как не может быть медленней JSONB.
И главная задача этой библиотеки это создание инфраструктуры для работы с EAV через индивидуальную таблицу для данных которые часто обновляются или для работы через материализованное представление для данных которые обновляются крайне редко.
JSONB затащили в постгрес что бы утереть нос MongoDB и прочим. Почему стали популярны документарные БД? потому что не надо заморачиваться на работу со схемой базы данных, во первых это же надо кроме языка программирования научиться разбираться с DDL, что то понимать в СУБД. Второе надо написать библиотечку для работы с EAV и по пути собрать море граблей.
Правильно что ни кто не это не заморачивается, для стартапов это не нужный риск.
А если ты пишешь код для себя, исключительно из академического интереса, то почему бы и нет.
Мне было интересно проверить концепцию, я её проверил и сделал это ещё три года назад в 2018 году когда написал статью «Идеальный каталог, оптимизация выборки данных».
Разработка библиотеки это ещё одно доказательство в пользу жизнеспособности идеи.
И я думаю что эта идея была реализован и не раз, просто в инхаус системах, поэтому широкой публике не известна.
Всему своё место и время. Если джуну в его коде надо что то из базы прочитать, то зачем отвлекать на написание этого кусочка программиста СУБД ?
Разработка это прежде всего производство и чем ниже требования к квалификации тем больше сотрудников можно привлеч к этому производству. Любые библиотеки снижающие требования к квалификации помогаю производству.
Ни кто не запрещает пользоваться сырыми запросами через эту библиотеку или любую другую.
Вы свободны в своём выборе. Вам дают инструмент, а вы можете им не пользоваться, кто то другойосвоиться с ним и ему это будет полезным.
Кворум на общем собрании это 50% и один голос, а не 51%. По каким то вопросам надо 50% ЗА, по другим две трети ЗА, В законах множество нюансов, суду потом не докажешь что приложение так посчитало или что приложение по другому не умеет, суд по букве закона рассудит. Статья относительно Жилищного кодекса очень поверхностная.
Как PR статья замечательная.
Я бы у нынешнего президента вообще не чего не спрашивал, его ответ был есть и будет: "все хорошо, прекрасная маркиза".
Кто то может мне напомнить когда он произносил другие речи ?
Вы сами в это верите? код будет написан под ваш бизнес, но вероятность того что он будет ЛЕГКО масштабироваться и меняться близка к нулю.
Писать код так что бы он легко менялся и масштабировался надо уметь, дело не в том что бы писать под бизнес, дело в том что бы уметь так писать и не лениться так делать.
Сколько живу — ни разу не видел. У Яндексов спросите сколько раз они переписывали свои приложения и сколько там легаси, кода унаследованного и в котором ни кто ни когда не будет разбираться, который при необходимости — заменят другим, но ни когда не будет в нём разбираться.
Continuos delivery, миграции, репозитории нужны для переносимости кода, для отчуждаемости кода от разработчика.
Миграция которая создаёт колонку, почему она не должна упасть если в таблице присутствуют какие то другие колонки? Кажется я повторяюсь.
Ваше возмущение по поводу владельцев кода, это что то с чем то. Вас не возмущает что работу между сотрудниками делят по отделам? что каждая команда отвечает за свой функционал или фичу? нет? странно.
Сервис ориентированная архитектура не слышали? Каждый микро-сервис со своим стеком технологий? нет?
Владелец продукта?
У кода не может быть владельца? у Фичи?
Кроме того, у нас сейчас работа ведётся одновременно в 30-ти ветках, то есть одной таблицы будет 30-ть копий, влитые ветки в мастер ни кто не удаляет, то есть у нас на текущий момент могло бы быть 1800 версий одной и той же таблицы.
Сложно администрировать такое хозяйство.
Вы в курсе что такое миграции и как они работают? Если миграция создает колонку в таблице, то она упадет только если такая колонка уже создана. Ни один механизм миграцийни когда не проверяет что схема бд находиться в каком то преопределенном состоянии.
Миграции это способ версионировать схему базы данных. Каждая миграция это аналог камита. Каждая миграция это изменение состояния между до миграции и после миграции. Но в отличии от версионирования у миграцийнет дерева. Нет механизма для записи осередности применения измененийк схеме базы данных.
На уровне БД если эти проверки делать, то потребуется для каждой версии кода, делать свою версию бд, свои инстанс.
Не айс.
Проблема не в том что таблицу правит два разных человека которые между собой не договариваются, проблема в том что для одной фичи нужны одни колонки, для другой другие, и какие то колонки могут после проверки гипотезы на драфте умереть на всегда.
А приложение не должно падать от таких вещей. Если приложению важно что бы какие то данные соответствовали каким то требованиям, то эти требования надо проверять на уровне приложения, а не БД, потому что БД одна, а версий приложения с десяток.
Перекраивать БД под каждую конкретную версию кода не реально (ветки фич иногда приходиться сливать в одну ветку и тестировать их совместную работу)
Мне кажется у вас не было опыта подобной разработки, поэтому вам сложно уловить на слух, это та вещи которую надо увидеть.
Есть разница между пет проектами, ин-хаус для фирмы на пару тысяч сотрудников и для приложения которое работает с десятками тысяч пользователей с функционалом объёма примерно обычной CRM системы, в которой лидов 100500 вариантов и каждый вариант обрабатывается уникальным образом.
Размер колонок меняется миграцией в любую сторону. Разве это проблема?
Но на самом дела колонки всегда надо создавать максимальной длины. Современным СУБД не важно колонка 10 символов или 100, если в неё пишется только 5, то места на диске будет занято только на 5 символов.
При желании тип колонки можно поменять в миграции. Если колонку добавили недавно, то это не проблема. Если колонку добавили давно, то просто добавляем новую колонку и работаем только с ней, старую колонку не пишем и не читаем.
Работать с таблицами через select *, это всегда был дурной тон. Всегда надо указывать колонки которые вас действительно интересуют.
И на самом деле в таблице должны быть колонки для индексов и одна колонка data в которую пишется json с бизнес данными. Но это высший пилотаж. Для тех кто понимает что такое база данных.
Если в таблице стало 200+ колонок и используется только 10. То почему не начать работать с новой таблицей?
Первый релиз делаем миграцию с новой таблицей и пишем посев данных с переносом данных из одной таблицы в другую, следующий релиз меняем в моделе имя таблицы и теперь мы работаем с новой таблицей в которой только нужные нам 10 колонок.
Их цель удовлетворение собственных аппетитов и ни чего более.
И если вы хотите что бы они заботились о вас, то вам надо сделать так что бы удовлетворение их аппетитов зависело от вашего благосостояния.
Сейчас не зависит.
Мне кажется их можно только самые простые делать в простом формате, хотите красоты — пользуйтесь не простыми форматами, используйте для этого навороченные редакторы.
С ручным выравниванием колонок я тоже намучался.
С другой стороны если будет возможность вставить картинку, то проще таблицу нарисовать в продвинутом редакторе и в документ вставить ссылку на картинку.
По части «Преформатированный текст», не соглашусь, писать ```php или ```sql не напрягает, 4 пробела подряд — очень спорное решение. Я понимаю что спец символов доступных из русской раскладки, не так много, но. Почему бы не сделать тройной символ;
С другой стороны что бы написать php всё равно надо раскладку переключить поэтому и символ ` тоже норм. Можно конечно вместо php писать «пхп», «скл», «иксмл», что бы не переключать раскладу, но мне кажется это будет слишком для консервативных умов.