Задача проста до нельзя. Спроектировать БД под большой интернет магазин с возможностью наращивать свойства и товары. Товары совершенно разные. Нужно быстро отображать данные по товарам и организовать быструю фильтрацию торов через поиск по фильтрам.
Свойства товаров привязаны к каталогам, грубо говоря у товара в каталоге могут быть только те свойства которые есть у этого каталога. Свойства бывают разных типов: число, булевое, строка, выбор из списка и могут быть множественными значениями, когда у одного свойства для товара может быть несколько значений.
В своем прототипе я использовал именно EAV с разбиением значений по таблицам с разными типами. Спроектировать запросы было сложно, пришлось писать довольно сложный алгоритм который на лету понимал что от него требуется и генерировал SQL запрос максимально оптимизировавшийся его. В целом поиск по 40к тестовым товарам и где-то по 300 свойствам работает шустро, но я планирую что товаров должно быть около 200к и около 2к свойств
unfilled, теперь я понял про что вы говорите, я применял такой подход когда разрабатывал проект для оформления заявок на участие в разных мероприятиях для фестиваля. Там была общая таблица для списка заявок, они были разбиты по типам и для каждого типа была таблица со своим набором полей.
Но в рамках большого интервент магазина не думаю что это применимо, так как разновидностей товаров очень много и под каждый вид плодить таблицы не вариант, что в конечном итоге возвращает нас к началу проблемы. :(
unfilled, у нас свойства привязаны к иерархии каталога, грубо говоря для каждой конечной папки каталога свой набор характеристик из общего списка характеристик, но при таком подходе будет огромное количество таблиц, я так понимаю когда вы говорите про категории, речь идет о другом, например: Основные свойства, свойства для поиска, прочее и так далее.
Можно поподробнее Пров арканит 2.2, заинтересовал такой подход, выглядит вполне дееспособным, но хочется уточнить про категории, в идеале с примерами для лучшего пониманиям.
Ezhyg, При всем уважении . вам писал что пример с одним символом был приведен для удобства, если там будет любой другой набор символов будет тоже самое. Причем не зависит это от типа передачи, будь то бинарный или текстовый. В файле происходит побитовый сдвиг данных начиная примерно с середины файла. Размеры файлов бит в бит совпадают.
Антон: ну вроде как понимание того как через composer сделать грамотно подключение и установку модулей у меня появилось, прошу посмотреть сам пост, я его отредактировал убрав под сполер сам изначальный вопрос и написав решение придуманное на текущий момент, жду комментариев и критики.
ага, то есть как я понимаю в админке пишется интерфейс который при запросе пакета запускает сначала композер, устанавлвиает пакет, затем как-то из композера возвращает данные о том куда был установлен пакет и после передает эти данные в мой скрипт который уже лезет в папку и ищет в ней конфигурационные файлы, я вас верно понял?
oxidmod: блин, дело то не в этом, пусть кладет, я просто не понимаю как моя CMS система узнает что это модуль? То есть ей надо каждый раз сканить папку Vendors на наличие там папок с файлами конфигурацией. Просто как мне кажется это не очень практично или я не прав? Когда ты инсталлируешь пакет через свой инстоллятор в админке, тут все понятно. Разархивирвоал архив, считал оттуда файл конфигурации, сделал нужные записи в базу и файлы из архива положил в нужный каталог. На этом все. Но когда работает композер, то он просто скачивает запрошенный файл и тянет к нему описанные зависимости размещая все в папке вендор. А как сделать эту постнастройку. Композер вроде как умеет поддерживать скрипты какие-то которые стартуют перед и после установки, но не уверен что они тут приемлемы будут.
oxidmod: ну она и будет одна, класс управляющий, но вот в чем загвоздка, один хрен надо сканить все файлы в на наличие нужного, что есть затратно, ведь назвать свой класс чувак может как угодно и где угодно в своем неймспейсе разместить, просто попахивает какой-то анархией в файлах.
oxidmod: такой вариант я предполагал выше, но для его реализации надо каждый раз сканить папку vendors и все вложения на поиски файлов которые могут быть модулями. В общем мне кажется это не очень вариант. Есть идеи как еще это реализовать, так как пока это одна из главных причин не использовать Composer для реализация модулей
oxidmod: о как... забавно, я похожим образом с GIT работаю. Но пара моментов остается все равно непонятными. Смотри, как бы мне при установки того или иного модуля (речь идет про модуль моей CMS а не библиотеку) занести данные о нем в определенном формате, например сделать запись в соответствующую таблицу где хранится список модулей. Ну когда ты руками добавляешь проект а потом руками вносишь данные в конфигурацию тут все понятно, но мне нужно автоматизировать этот процесс. То есть если скачался именно модуль а не библиотека, то при этом надо выполнить некий код, например сделать запись об этом модуле в базу.
oxidmod: так уже интереснее, это все понятно, если можно поподробнее про "в некий конфиг прописывается модуль" и "после того, как модуль добавлен в список он появляется в админке". Как это сделать ручками то я понимаю, в процессе разработки с этим нет проблем, в моем случае данным конфигом является таблица в базе данных в которой хранится информация о модулях, зависимостях и прочем необходимом для ядра. Но вот вопрос в чем. Чувак зашел в админку и захотел установить через какой-то интерфейс Composer новый модуль, как сделать так чтобы установщик Composer понял что это именно модуль а не просто библиотека и что надо внести какие-то правки в конфигурацию, например добавив в список модулей данные об новом установленном модуле.
oxidmod: могу и походим образом делаю, но чтобы вызвать метод мне сначало надока к сто CMS сообщить что это именно модуль а ен просто класс или он должен по всем файлам пробегать сканить их на наличие интерфейса и вносить их в список модулей? глупо. Опять же не вижу описания того как изменить данные в базе, СОЗДАТЬ НУЖЫНЕ ТАБЛИЦЫ и изменить уже записанные данные?
oxidmod: ага это вы объясните например директору компании который говорит что я хочу вот это но чтобы работало вот так вот и программисту приходится писать свой модуль. Вопрос нахрена ему его заливать в Composer? Еще раз, Composer хорош для подгрузи вспомогательных библиотек, но юзать его чтобы хранить там файлы проекта это тупо как по мне, а если файлы проекта там не хранить, то тогда как другие люди которые будут дорабатывать проект независимо друг от друга будут использовать пространство имен? Крмое того Composer это контролер зависимостей библиотек, он не умеет изгаляться и при скачивании библиотеки выполнять еще код изменяющий данные в базе данных, кроме того как я писал неоднократно что те же файлы шаблонов смысла хранить в неймспейсе нет, их вообще по хорошему надо выносить в отдельный файл, но и тут свои траблы возникают, когда часть у нас в Composer а часть в своих папках, плюс еще даныне котоыре надо внести в базу...
Зря, не делайте глупость. Автолоад и управление зависимостями - это решенная задача. Ваш вариант не будет лучше, примите за исходную.
автоподключение классов будет, тут речь идет не о том что я не хочу юзать composer я имею в виду что не вижу его применения в рамках реализации элементов CMS системы.
попытаюсь прояснить ситуацию так как складывается впечатление что я что-то не то пытаюсь объяснить.
Ну вот к примеру с помощью composer я подрубил к проекту все нужные мне библиотеки. Супер. На основе их я реализовал модуль для сайта "Shop" и положил его в .\frontend\modules\Shop\<файлы модуля> но потом мой код взял мой знакомый и решил что захотел реализовать свой магазин и вот куда он должен класть свои файлы если он тоже хочет чтобы его модуль назывался Shop?
как я понял мне предлагают все файлы класть в папку vendor\zaitsev\modules\Shop\<файлы модуля> но блин тогда все мои файлы будут лежать в папке vendor, а что будет лежать в других файла? а шаблоны которые с мобулем идут их тоже туда пихать? что-то я не сосем этого понимаю зачем это делать. Ок, я согласен что composer хорош при подключении вспомогательных библиотек при разработке, но если я хочу разрабатывать крупные модули то накой мне все элементы валить в composer если например шаблоны я бы хранил вообще отдельно что вполне логично, да и шаблоын могут для одного и тогоже модуля быть от разных поставщиков. В общем меян именно этот момент интересует. А если это делать в рамках проекта, то есть не размещать файлы проекта в том чесле модулей в папке vendor, то тогда встает вопрос а как решить ту самую проблему с наименованием папок если два разных чувака работая над проектом независимо решили запилить одноименный модуль?
oxidmod: нет, зависимости контролируются наследованием, структура лишь нужна для типизации данных, чтобы каждый мог залезть в код модуля и при необходимости поправить то что ему надо потому что он знает например что в этой папке контролеры, в этой библиотеки, а тут шаблоны
oxidmod: то есть насколько я понимаю я могу запилить свой код и залить его в репозиторий Composer чтобы другие чуваки его могли скачивать для себя, допустим, это конечно неплохо, но как заставить Composer чтобы он после скачиавания пакета как-то понял что это не просто библиотека а именно модуль, что для него надо создать определенный таблицы в базе и что надо внести в базу админки ряд изменений?
Свойства товаров привязаны к каталогам, грубо говоря у товара в каталоге могут быть только те свойства которые есть у этого каталога. Свойства бывают разных типов: число, булевое, строка, выбор из списка и могут быть множественными значениями, когда у одного свойства для товара может быть несколько значений.
В своем прототипе я использовал именно EAV с разбиением значений по таблицам с разными типами. Спроектировать запросы было сложно, пришлось писать довольно сложный алгоритм который на лету понимал что от него требуется и генерировал SQL запрос максимально оптимизировавшийся его. В целом поиск по 40к тестовым товарам и где-то по 300 свойствам работает шустро, но я планирую что товаров должно быть около 200к и около 2к свойств