На мой вкус пустую строку можно на вход получить, её надо интерпретировать как 0.
Валидацию на не цифровые символы я бы сделал регулярным выражением.
И конечно в эксепшенах надо давать намёк на причину ошибки, лучше давать подсказки о том как ошибку исправить.
Так или не так, проверяется юнит тестами.
На PHP это делается одной командой :)) Поэтому к этому тестовому надо давать комментарий о том что требуется решить через алгоритм сложения в столбик, то есть с контролем переполнения десятичной позиции.
На сайте 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 вариантов и каждый вариант обрабатывается уникальным образом.
Автор спасибо за статью. Можно код на git hub выложить ?
На мой вкус пустую строку можно на вход получить, её надо интерпретировать как 0.
Валидацию на не цифровые символы я бы сделал регулярным выражением.
И конечно в эксепшенах надо давать намёк на причину ошибки, лучше давать подсказки о том как ошибку исправить.
Так или не так, проверяется юнит тестами.
На PHP это делается одной командой :)) Поэтому к этому тестовому надо давать комментарий о том что требуется решить через алгоритм сложения в столбик, то есть с контролем переполнения десятичной позиции.
"Папки больше не пытаются рендериться с иконками, которые показывают превью содержимого папок. Это извращение времён Vista уже забыто."
На самом деле иногда это удобно.
да, август 2021 последний месяц когда будут выходить обновления.
На сайте 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 вариантов и каждый вариант обрабатывается уникальным образом.