Доставляет всё, где нужно хоть чуть-чуть думать своим мозгом при трассировке. Я предпочитаю видеть результат выполнения программы глазами, а не мозгом :)
Вы правильно понимаете и ваш подход имеет право на существование. Я просто описал EAV-структуру данных, которая реализована в Magento 2. Одна из многих.
catalog_category_entity — это реестр категорий. В нём генерируются ID для отдельных экземпляров сущности типа "категория каталога". Обычно таблица-реестр содержит также и значения атрибутов сущностей в виде колонок в этой же таблице. Но ни о какой группировке на уровне структур данных в этом случае речь не идёт. Каждая строка (экземпляр сущности) содержит все колонки, которые есть в таблице.
Теоретически, мы можем в catalog_category_entity добавить колонку attr_group, фиксировать там имя группы набора атрибутов и программно фильтровать, какие колонки (атрибуты) показывать для каких наборов (если я правильно понял вашу мысль), но в таблице всё равно каждая строка будет содержать null для неиспользуемых данным набором атрибутов колонок, и для неё будет зарезервировано место на диске.
Другими словами в таблице на 500 колонок для каждой строки место на диске выделяется на все 500 колонок, даже если по факту в данной строке всегда будет использоваться всего 10 колонок.
И большинство из них работают с миграциями — командами для внесения инкрементных изменений в схему базы данных.
Я не очень глубоко влазил в Doctrine по этому вопросу, но у меня сложилось впечатление, что Doctrine DBAL считывает текущую схему данных из базы, позволяет разработчику через PHP-код модифицировать её путем удаления/добавления таблиц/столбцов, затем сама генерирует набор SQL-запросов, переводящих структуру данных из начального состояния в желаемое.
Разумеется, что делает она это не настолько хорошо, как это может сделать сам разработчик на чистом SQL, заточенном под конкретную СУБД, но меня во всём этом привлекает идея создания моделей схемы данных — начальной и конечной. Doctrine создает модель в памяти из PHP-объектов, но можно модель описывать в виде XML/JSON/YAML/… В этом случае вся схема данных, допустим в XML, ложится под стандартный контроль версий (как и SQL-файлы).
Для двух различных моделей схем данных можно прогонять миграцию прямую и обратную (rollback). Два развития одной базовой модели от двух (и более) разных девелоперов можно прогнать через процедуру слияния (текст структурированный), либо вообще собирать конечную модель из отдельных фрагментов, где каждый девелопер сам развивает свой участок общей схемы данных.
Для таблиц такой структурированный подход уже работает (Magento 2.3). Для views/triggers/procedures/… более проблематично (здесь, скорее всего, пойдут вставки чистого SQL, что нивелирует преимущества структурирования информации).
Тем не менее, если не увлекаться DB-программированием (триггеры и SQL-процедуры), то можно достаточно успешно структурировать SELECT, который лежит в основе создания views. А tables & views — основа схемы данных. Т.е., если переводить XML/JSON/YAML-модель в Doctrine-модель, то далее Doctrine DBAL уже сама сможет выполнять миграцию.
Это не универсальное решение, оно однозначно не подойдёт для крупных проектов, где БД является центром Вселенной и доводиться вручную "до блеска". Но для проектов, типа Magento, где конечное приложение собирается из отдельных модулей (как следствие, конечная схема данных собирается из отдельных фрагментов) — может оказаться вполне удачным.
Что значит в данном контексте "валидный токен"? Может ли у одного и того же пользователя (с одним и тем же внутренним идентификатором на сервере) быть два разных валидных токена? Что делать, если пользователь "засветил" свой токен перед злоумышленником и теперь хочет поменять его?
Филдинг описал концепцию построения распределённого приложения, при которой каждый запрос (REST-запрос) клиента к серверу содержит в себе исчерпывающую информацию о желаемом ответе сервера (желаемом представительном состоянии), и сервер не обязан сохранять информацию о состоянии клиента («клиентской сессии»).
Это из вики. Получается, что таблица с авторизационными токенами на сервере — это не REST. Если подходить строго, то REST возможен только при HTTP Basic аутентификации. Только тогда сам запрос содержит в себе достаточно информации, чтобы сформировать ответ. При этом на каждый запрос нужно будет проводить аутентификацию и авторизацию.
Но токен же должен храниться и на клиенте, и на сервере, чтобы можно было обеспечить аутентификацию/авторизацию? И по мне, так нет никакой принципиальной разницы с точки зрения stateless, как передавать токен с клиента на сервер — в заголовке Cookie или в заголовке Authorization.
В общем случае запросы клиента могут с помощью балансировщика направляться на разные сервера
Вот и вопрос, как же тогда разные сервера определяют, анонимный клиент дал запрос или он уже аутентифицирован ранее и имеет права на доступ к restricted-данным?
Как-то меня смущает во всей этой холиварне слово "stateless". На большинстве сайтов, с которыми лично я сталкиваюсь, требуется аутентификация/авторизация, а это уже, как минимум, два состояния: анонимный и аутентифицированный.
Отсюда: "Обращаем ваше внимание на то, что счетчик учитывает посещаемость только тех страниц сайта, на которых он установлен. Для более полной статистики рекомендуем вам вставлять html-код счетчика на все страницы сайта."
Что-то вы не туда посмотрели. Вот первая статья за вчера:
На FB её перепостили 67 человек, в favorites поставили 88. Таких статей за вчера было 7. А вы говорите за 60 человек в день на всего Кассада? С такой статистикой, как у вас, вполне можно прийти к выводу, что "ЖЖ превратился в богом забытую площадку, наполненную мертвыми душами и желтухой в топе".
Возможно, когда-то ЖЖ был всем для всех, но вполне закономерно, что с появлением альтернатив народ разбежался по местам, где кому удобнее. И это не трагедия, а эволюция.
Получается, что 5.8К посетителей блога Варламова, которые отметились там за последние сутки, ничего не объединяет — ни интересы, ни предпочтения, ни привычки? У них нет связи друг с другом и эти дискуссии в комментах:
не относятся к общей деятельности? И эти 5.8К такие же случайные прохожие, как 4.7К COLONELCASSAD'а (Рупор тоталитарной пропаганды) и 4.3К MISS_TRAMELL («Меня читают красивые люди!»)?
Нет, вам показалось.
Согласен.
Доставляет всё, где нужно хоть чуть-чуть думать своим мозгом при трассировке. Я предпочитаю видеть результат выполнения программы глазами, а не мозгом :)
Вы правильно понимаете и ваш подход имеет право на существование. Я просто описал EAV-структуру данных, которая реализована в Magento 2. Одна из многих.
catalog_category_entity— это реестр категорий. В нём генерируются ID для отдельных экземпляров сущности типа "категория каталога". Обычно таблица-реестр содержит также и значения атрибутов сущностей в виде колонок в этой же таблице. Но ни о какой группировке на уровне структур данных в этом случае речь не идёт. Каждая строка (экземпляр сущности) содержит все колонки, которые есть в таблице.Теоретически, мы можем в
catalog_category_entityдобавить колонкуattr_group, фиксировать там имя группы набора атрибутов и программно фильтровать, какие колонки (атрибуты) показывать для каких наборов (если я правильно понял вашу мысль), но в таблице всё равно каждая строка будет содержать null для неиспользуемых данным набором атрибутов колонок, и для неё будет зарезервировано место на диске.Другими словами в таблице на 500 колонок для каждой строки место на диске выделяется на все 500 колонок, даже если по факту в данной строке всегда будет использоваться всего 10 колонок.
Выбрал .net — не спишь по ночам, пытаясь восстановить связь с реальностью.
Шутка. Интересная публикация (y)
очередная попытка захвата мира.
из выдуманного.
MyISAM
Я не очень глубоко влазил в Doctrine по этому вопросу, но у меня сложилось впечатление, что Doctrine DBAL считывает текущую схему данных из базы, позволяет разработчику через PHP-код модифицировать её путем удаления/добавления таблиц/столбцов, затем сама генерирует набор SQL-запросов, переводящих структуру данных из начального состояния в желаемое.
Разумеется, что делает она это не настолько хорошо, как это может сделать сам разработчик на чистом SQL, заточенном под конкретную СУБД, но меня во всём этом привлекает идея создания моделей схемы данных — начальной и конечной. Doctrine создает модель в памяти из PHP-объектов, но можно модель описывать в виде XML/JSON/YAML/… В этом случае вся схема данных, допустим в XML, ложится под стандартный контроль версий (как и SQL-файлы).
Для двух различных моделей схем данных можно прогонять миграцию прямую и обратную (rollback). Два развития одной базовой модели от двух (и более) разных девелоперов можно прогнать через процедуру слияния (текст структурированный), либо вообще собирать конечную модель из отдельных фрагментов, где каждый девелопер сам развивает свой участок общей схемы данных.
Для таблиц такой структурированный подход уже работает (Magento 2.3). Для views/triggers/procedures/… более проблематично (здесь, скорее всего, пойдут вставки чистого SQL, что нивелирует преимущества структурирования информации).
Тем не менее, если не увлекаться DB-программированием (триггеры и SQL-процедуры), то можно достаточно успешно структурировать SELECT, который лежит в основе создания views. А tables & views — основа схемы данных. Т.е., если переводить XML/JSON/YAML-модель в Doctrine-модель, то далее Doctrine DBAL уже сама сможет выполнять миграцию.
Это не универсальное решение, оно однозначно не подойдёт для крупных проектов, где БД является центром Вселенной и доводиться вручную "до блеска". Но для проектов, типа Magento, где конечное приложение собирается из отдельных модулей (как следствие, конечная схема данных собирается из отдельных фрагментов) — может оказаться вполне удачным.
О! Вот это то самое! Спасибо :)
Что значит в данном контексте "валидный токен"? Может ли у одного и того же пользователя (с одним и тем же внутренним идентификатором на сервере) быть два разных валидных токена? Что делать, если пользователь "засветил" свой токен перед злоумышленником и теперь хочет поменять его?
Это из вики. Получается, что таблица с авторизационными токенами на сервере — это не REST. Если подходить строго, то REST возможен только при HTTP Basic аутентификации. Только тогда сам запрос содержит в себе достаточно информации, чтобы сформировать ответ. При этом на каждый запрос нужно будет проводить аутентификацию и авторизацию.
Но токен же должен храниться и на клиенте, и на сервере, чтобы можно было обеспечить аутентификацию/авторизацию? И по мне, так нет никакой принципиальной разницы с точки зрения stateless, как передавать токен с клиента на сервер — в заголовке
Cookieили в заголовкеAuthorization.Вот и вопрос, как же тогда разные сервера определяют, анонимный клиент дал запрос или он уже аутентифицирован ранее и имеет права на доступ к restricted-данным?
Как-то меня смущает во всей этой холиварне слово "stateless". На большинстве сайтов, с которыми лично я сталкиваюсь, требуется аутентификация/авторизация, а это уже, как минимум, два состояния: анонимный и аутентифицированный.
Отсюда: "Обращаем ваше внимание на то, что счетчик учитывает посещаемость только тех страниц сайта, на которых он установлен. Для более полной статистики рекомендуем вам вставлять html-код счетчика на все страницы сайта."
Что-то вы не туда посмотрели. Вот первая статья за вчера:
На FB её перепостили 67 человек, в favorites поставили 88. Таких статей за вчера было 7. А вы говорите за 60 человек в день на всего Кассада? С такой статистикой, как у вас, вполне можно прийти к выводу, что "ЖЖ превратился в богом забытую площадку, наполненную мертвыми душами и желтухой в топе".
Возможно, когда-то ЖЖ был всем для всех, но вполне закономерно, что с появлением альтернатив народ разбежался по местам, где кому удобнее. И это не трагедия, а эволюция.
Откуда такая цифра — 60 в день?
Получается, что 5.8К посетителей блога Варламова, которые отметились там за последние сутки, ничего не объединяет — ни интересы, ни предпочтения, ни привычки? У них нет связи друг с другом и эти дискуссии в комментах:
не относятся к общей деятельности? И эти 5.8К такие же случайные прохожие, как 4.7К COLONELCASSAD'а (Рупор тоталитарной пропаганды) и 4.3К MISS_TRAMELL («Меня читают красивые люди!»)?
Если так, то да — ЖЖ-комьюнити разрушено.
А чем "комьюнити" в вашем понимании отличается от "вообще людей"?