Согласен. Просто стиль написания довольно своеобразный, много слов проглатывается пока Вы летаете в своём воздушном замке. Иллюстрация могла бы многое прояснить.
Очень хорошо, когда у нас есть только разные виды уток. Неплохо, так же, когда кроме уток есть разные виды котиков.
Но становится очень нехорошо, когда у нас есть стреляющая утка и стреляющий котик, а мы располагаем только наследованием.
Вот тут начинается нетривиальное пересечение умений.
В православных языках запрещено множественное наследование, можно только реализовывать множество интерфейсов, но это ведёт к повторению кода.
Выход их этой ситуации — композиция. Именно так получается то, что никак не связанные друг с другом утка и котик умеют одно и то же.
Причём композиция тоже может наследоваться, когда мы собираем её фабрикой, а потом расширяем фабрику так, чтобы она давала эту же композицию и дополнительно несколько новых умений.
Несмотря на то, что этот вопрос мне задаёт большинство людей, которые знают чем я занимаюсь, легче найти специалиста который хорошо разбирается в «традиционных» БД, чем человека который имеет опыт работы с документоориентированными базами данных. Ну а конкретно в этом случае, при проектировании ИС люди просто не знали о существовании таких БД.
В данном случае модель была выбрана, когда я ещё не участвовал в проекте.
Модель EAV имеет один плюс и много минусов, и очень важно сразу понять — так ли необходим этот плюс. Достоинства EAV:
— Управление сущностями используя DML (Data Manipulation Language), а именно — создание и редактирование сущностей без использования операций CREATE TABLE и ALTER TABLE. При грамотном подходе это даёт поразительную гибкость базы данных. Недостатки EAV:
— Относительно низкая скорость работы
— Каждый запрос несёт за собой большое количество рутинного кода для вытаскивания данных
— Относительно высокий порог вхождения специалистов
Таким образом EAV подходит для очень динамичных информационных систем, где скорость изменения структуры данных важнее скорости их получения.
Из личного опыта могу сказать, что эта модель бессмысленна, когда нет инструментов её обслуживания — редакторов сущностей, унифицированных компонентов информационной системы для отображения объекта/списка объектов, универсальных форм заполнения объектов и т.д. Ведь если для любого изменения приходится лезть в код, то почему не сделать это хотя-бы традиционно?
А я и не говорил, что это методы обработки коллекций. Я с самого начала написал, что здесь от LINQ используется только факт написания запроса на «родном» языке. И далее я говорю именно о генерации строки запроса. Даже само название основного класса говорит об этом — Query Builder.
И когда я его писал, я не пытался сделать его похожим на LINQ. Генератор запросов нужен чтобы упростить написание запросов.
что проще:
?
С другой стороны, у меня написано о применении такого подхода к EAV. Умеет ваш Doctrine работать с EAV? Буду вам очень признателен, если подскажете мне ORM для EAV.
Возможно я консервативный динозавр, наподобие тех что телевизор тряпочкой накрывают, но всёже время надо проводить занимаясь более материальными занятиями, чем созерцание разноцветных огоньков на мониторе. Чувство собственного достоинства не позволяет мне считать видеогры, чтение блогов или просмотр сериаллов достойным хобби.
Несмотря на то что я всегда считал что интернет — зло, и его главная задача — быть хранилищем информации, а не средством развлечения, я тоже на него подсел.
Кто-то говорит о том что наличие интернета даёт выбор — пользоваться им ли нет. Однако поначалу он слишком хорош, чтобы от него отказываться, а потом ты понимаешь, что слишком долго сидел в этой трясине и много чего тебя в ней держит.
Являясь уже неотьемлемой частью цивилизации, интернет в развивающихся странах будет желанным. Какой тут может быть выбор..?
Я и не говорил что пузыри надо создавать прямо на планете. Что касается любопытсва — именно тот факт, что цель не обязательно будет достигнута, говорит о том что люди хотят узнать и надеются что что-то из этого получится.
Можно предположить, что человечеством может двигать не только угроза гибели, но и простое любопытсво. Но если вдруг эта угроза появится и будут доступны технологии позволяющие производить тоннами антиматерию или искривлять пространство — зачем тогда куда-то лететь, когда можно теми же методами синтезировать любые химические элементы, создавать безопасные «пузыри» и накрывать целые страны парусами отражающими вредное излучение?
Вы правы. UTF-8 это multibyte кодировка где количество символов не является количеством байт строки. Поэтому если бы я делал upload файла, то такой способ вычисления длинны тела запроса привёл бы к ошибке.
Однако в нашем случае отправляемые данные сериализуются модулем querystring, в результате чего кирилица заменяется на спецсимволы, что позволяет обойти этот опасный момент.
За require('config.json'); спасибо, не знал.
А вот файлы с кирилицей в UTF-8 отправлял и ничего страшного при этом не происходило. Думаю дело в том что я отправляю именно строку а не файл.
Вы несомненно правы, и существует множество решений именно для этой цели предназначенных.
Однако ни одно из них сервер не поддерживает, а изменение сложившийся ситуации не в моей власти.
Но становится очень нехорошо, когда у нас есть стреляющая утка и стреляющий котик, а мы располагаем только наследованием.
Вот тут начинается нетривиальное пересечение умений.
В православных языках запрещено множественное наследование, можно только реализовывать множество интерфейсов, но это ведёт к повторению кода.
Выход их этой ситуации — композиция. Именно так получается то, что никак не связанные друг с другом утка и котик умеют одно и то же.
Причём композиция тоже может наследоваться, когда мы собираем её фабрикой, а потом расширяем фабрику так, чтобы она давала эту же композицию и дополнительно несколько новых умений.
Модель EAV имеет один плюс и много минусов, и очень важно сразу понять — так ли необходим этот плюс.
Достоинства EAV:
— Управление сущностями используя DML (Data Manipulation Language), а именно — создание и редактирование сущностей без использования операций CREATE TABLE и ALTER TABLE. При грамотном подходе это даёт поразительную гибкость базы данных.
Недостатки EAV:
— Относительно низкая скорость работы
— Каждый запрос несёт за собой большое количество рутинного кода для вытаскивания данных
— Относительно высокий порог вхождения специалистов
Таким образом EAV подходит для очень динамичных информационных систем, где скорость изменения структуры данных важнее скорости их получения.
Из личного опыта могу сказать, что эта модель бессмысленна, когда нет инструментов её обслуживания — редакторов сущностей, унифицированных компонентов информационной системы для отображения объекта/списка объектов, универсальных форм заполнения объектов и т.д. Ведь если для любого изменения приходится лезть в код, то почему не сделать это хотя-бы традиционно?
И когда я его писал, я не пытался сделать его похожим на LINQ. Генератор запросов нужен чтобы упростить написание запросов.
что проще:
или
?
С другой стороны, у меня написано о применении такого подхода к EAV. Умеет ваш Doctrine работать с EAV? Буду вам очень признателен, если подскажете мне ORM для EAV.
Вчера только такой купил.
Кто-то говорит о том что наличие интернета даёт выбор — пользоваться им ли нет. Однако поначалу он слишком хорош, чтобы от него отказываться, а потом ты понимаешь, что слишком долго сидел в этой трясине и много чего тебя в ней держит.
Являясь уже неотьемлемой частью цивилизации, интернет в развивающихся странах будет желанным. Какой тут может быть выбор..?
Однако в нашем случае отправляемые данные сериализуются модулем querystring, в результате чего кирилица заменяется на спецсимволы, что позволяет обойти этот опасный момент.
А вот файлы с кирилицей в UTF-8 отправлял и ничего страшного при этом не происходило. Думаю дело в том что я отправляю именно строку а не файл.
Однако ни одно из них сервер не поддерживает, а изменение сложившийся ситуации не в моей власти.