АнатоЛойНет, просто ваш комментарий на него меня озадачил. Решил уточнить :)
Мой комментарий был на Ваше оскорбление:) Я всегда так комментирую сообщения не по существу вопроса.
АнатоЛойНе опускаясь в технические детали: на этом уровне они излишни.
Уверен, что у Вас их нет:) На каком еще "этом уровне"?
АнатоЛойБыли отличные технические детали от V&N. Я же не агитировал за другие варианты, типа mumps :). Вот и обозначил - агитация, никаких аргументов.
Из этого следует только то, что с mumps Вы не знакомы. И Вам приходится использовать термин "агитация". Я здесь не собираюсь объяснять свойства mumps, так же, как и свойства "реляционных систем". Вам достаточно "отличных технических деталей" - это вполне нормально, могли бы обойтись без оскорбительных комментариев, не зная что такое mumps.
АнатоЛойЭто бесспорно. Надеюсь хоть в какой-то мере это взаимно :).
Конечно.

АнатоЛойБредятина, не уверен что должен, но всё-таки извиняюсь за употребление вашего ника "вслух" в гордом одиночестве в своём первом посте :) (если с вашей точки зрения "комментарий не по существу вопроса" приравнивается к оскорблению). Вы же сами этим ником провоцируете .
Вы хотите придумать мне другой ник?:) Когда я зарегистрировался под своими фамилией, именем и отчеством меня тут же заблокировали из-за обсуждения вопросов по существу:)
АнатоЛойНе отрицаю, даже скорее уместнее термин "слышал". Я поставил себя на место ТС. Если уж вернуться "по существу темы" - а что, ТС с ней "знаком"?
Не уверен, что знаком, но считаю, что это (незнакомство) недопустимо для специалистов в области БД.
[quot АнатоЛой]
Ну то есть: вместо "Cчитаю, что mumps -наилучший вариант <потому-то из двух предложений>" ваша фраза не агитация? (говорю как экономист-маркетолог в том числе :)./quot]
Я здесь (на sql.ru) объяснял много раз и свойства mumps, и свойства "реляционных систем" и другие вопросы теории БД. mumps нужно знать человеку, который всерьез занимается БД.

Arhat109Бредятина, спасибо. Эти ссылки я уже читал и даже те, которые даны (в том числе и Вами) внутри этих ссылок. Все.
, к сожалению, ничего кроме общей демагогии о том что mumps "единственная" технология, я там НЕ нашел. Может плохо смотрел.
Очень плохо смотрели, причем, я не сомневаюсь, что Вы это и сами знаете:) Как меня здесь только не называли:) Разумеется, я - демагог:)
Arhat109, также жаль, с Вашим опытом работы с mumps, ожидал услышать о какой-нибудь поддержке, но отсылка на форум (где обычно решаются вопросы по ИСПОЛЬЗОВАНИЮ продукта/технологии), при заявленной необходимости лезть в потроха продукта (переработки исходника под плагин) - лично мне указывает, что внутренностей mumps - Вы не знаете, несмотря на столь долгий срок общения с ним. Жаль, если так.
Я Вам не просто поддержку оказал, а дал рекомендацию в надежности которой Вы, рано или поздно, убедитесь - Вы хотите решить бесполезную задачу. Поэтому я, не просто демагог, а еще и не знаю внутренностей:) Разумеется:)

Arhat109Бредятина,
извиняюсь за резкий тон предыдущего сообщения. Но
, что Вы предлагаете (мне, ТС, многим другим смотрящим в сторону EAV) реально ВМЕСТО общих рассуждений о том, что GT.M(Cache, Free.M, MSM, etc.) "единственная верная технология"?
Сначала напомню, что мы говорим не по теме.
Вы опять невнимательно читали:( Я не использую таких выражений. как "единственная верная". И очень ясно аргументирую. Вероятно, Вам следует обсуждать вопросы, связанные с EAV в соответствующих темах.
Arhat109На основной работе у меня есть те же проблемы, что и у ТС, а именно работа с произвольными параметрами товарных позиций.
Тема НЕ ПРО ЭТО СОВЕРШЕННО!
Arhat109На сегодня, отдельных категорий товаров - 250, планируется увеличение (есть уже черновой список) до 60_000. Общее число товарных групп по всем категориям "на сегодня" - 50000, планируется рост до 2млн., каждая товарная группа (ожидается) будет иметь от 5 до 150 параметров (много пересекающихся)... сейчас пока до 8шт.
Что посоветуете, при условии работающего Мускуля?
Искренне - НИЧЕГО.
Ответьте для себя, например, на такой вопрос: чем меня не устраивает drupal? В котором, кстати, активно используется EAV:)

Arhat109_мод, нажал случайно Enter, дополню:
"EAV" - Дык! Об чем и речь, что "Бредятина" утверждает, что это неверная модель данных
Неправда. Не следует говорить неправду в такой простой жизненной ситуации:)
Arhat109, и ваще Мускуль не РСУБД...
РСУБД создать не удалось. MySQL не только не РСУБД, но даже не СУБД.
Arhat109вот и вопрошаю, КАК сделать так, чтобы работало то, что по его мнению "единственно верное решение"... желательно без переписывания всего того что есть...
Гарантирую - никак.
Arhat109... имхо: сделать плагин к Мускулю. И пусть то что есть, на Мускуле и крутится, а вместо костыля EAV, использовать то самое "верное" решение... говорит неверная постановка задачи... а КАКАЯ будет верная?
Чудо какое-то:) Вы данные как собираетесь хранить в MySQL? Какая схема данных, которая как крутится, так и будет крутиться?

Arhat109ППЦ! Я - дал ВАМ ссылку на свою тему, Вы решили обсуждать здесь, приведя цитаты из моей темы (оттудова!)... и теперь оказывается, что я же и виноват, не хилый бред!
Я не решил:) И Вы не виноваты. Эта тема не имеет ни малейшего отношения к EAV. Это просто факт:) И вместо того, чтобы злиться нужно было внимательно читать темы по Вашему вопросу. А Вы продолжаете игнорировать все объяснения, которые там содержатся. Конечно, можно предложить, что просто не понимаете, но у меня складывается впечатление, что именно сознательно игнорируете.
Arhat109Для данной задачи (этой темы), мой небольшой опыт как раз подсказывает, что mumps - совершенно НЕПОДХОДЯЩЕЕ решение.
Небольшой опыт довольно часто приводит к ошибочным выводам. Вы заблуждаетесь, и вряд ли сможете технически объяснить что именно подсказывает Вам небольшой опыт:) Поскольку mumps уже 40 лет успешно используется для этой задачи:)
Arhat109Если надо писать 2000 записей в секунду, то самым быстрым решением будет писание сблокированных записей (хоть через Memcached, хоть просто в массиве памяти) на диск. И это - самое быстрое решение, потому что самое простое.
Только для записи - ни БД, ни СУБД, ни РСУБД, ни mumps - НЕ НУЖЕН.
А вот если потом надо будет читать, да по условиям, то и надо смотреть КАК будут организованы чтения, какие условия выборки и требования к временным параметрам чтения... и опять тут mumps - не причем. Нет тут ни сложной организации данных, ни разреженных деревьев, ни программ как данных, по сути ничего нет. Простая табличка.
Очень хорошо! Автору темы будет полезно услышать Вашу точку зрения. Простая табличка:) Но по совокупности приведенных Вами двух половинок (запись - чтение) - mumps превосходит другие системы баз данных. Этот факт давно и хорошо известен:)
Arhat109По вашему ответу: никак. Во-от, правильно говорите, правильно. И для задач EAV "по большому счету" mumps - не подходит, потому как не индексируется нормально.
Вы себя-то не запутывайте:) Никак - потому что MySQL. Зря Вы игнорируете подробные объяснения про EAV в соответствующих темах. В том числе, про "не нормальное индексирование". Вот здесь я уверен, что Вы просто не знакомы с mumps. Совсем:)
Arhat109Собственно мой опыт и был как раз попыткой решить эту модель на технологиях mumps. Несколько лучше чем костыль EAV, но все равно "та же фигня, вид сбоку". потому как (имхо) истина, где-то посередине.
Я Вам предложил пути размышлений. Задал конкретные вопросы. Но Вы - не читатель, Вы - писатель. И опять клоните к бесперспективному решению - "mumps-плагин к MySQL". Суть EAV в хранении данных. Если Вы будете разрабатывать СУБД, ориентированную на модель EAV, то должны знать о технологиях разработки СУБД. Иначе, конечно, "костыли". Просто поищите наилучший "костыль EAV" для MySQL, раз Вы выбрали MySQL для организации своей БД.

Arhat109Бредятина, по теме EAV и по теме mumps, перечитал здесь достаточно много, в том числе и темы датированные 2002годом.
Во-первых, mumps - не самая быстрая СУБД, как бы Вам не хотелось, чего из означенных тем почерпнуть таки можно. И уж тем более в версии Cache. Хотя бы потому, что итоговая конечная скорость складывается из многих факторов, что неплохо продемонстрировано здесь же в темах.
Вы пока недостаточно разобрались, хотя и перечитали много:) mumps - не СУБД, и мне никак не могло хотеться того, о чем Вы пишите. Обратитесь на форум, где есть специалисты в области технологий БД, в целом, и mumps, в частности (важен союз "и":)). Cache - не версия mumps. ISM (вероятно Вы ее имели в виду) - была весьма быстрой "версией", как Вы выражаетесь, и всегда отличалась расширениями стандарта. По поднятому Вами вопросу не нужно много читать, нужно читать ответы на Ваши вопросы, которые есть в приведенных темах.
Arhat109Прямой доступ к данным через B-деревья, безусловно быстрая технология, но она есть даже в Мускуле. Реализовать прямую обработку данных с прямой индексной выборкой через уже имеющийся(!) плагин я могу тоже. И без выкрутасов на идиотском жаргоне Васика - "М". На нормальном С/С++. Компилируемом.
"Доступ к данным через B-деревья" - такой жаргон говорит лишь о недостаточном понимании технологии БД. Вы "можете реализовать прямую обработку данных с прямой индексной выборкой на нормальном С" - это же великолепно! Причем, данных, хранимых в MySQL в виде структур EAV. Просто замечательно! Что за проблемы Вы себе придумали ранее не вполне понятно:)
Arhat109Во-вторых, к решению задачи, озвученной ТС mumps явно не подходит, хотя бы потому, что в нем "ВСЁ СУТЬ СТРОКА"... хранить float в строке конечно можно, и наверное с наукопознавательными целями полезно, но искать быстро трудно...
Полное непонимание предмета и технологий программирования, в том числе. Напомню, что C изначально был языком без типов. Это огромное преимущество, между прочим:)
Arhat109В третьих, наукообразное теоретизирование меня не интересует.
Но Вы только им и занимаетесь:) Уточню - технологии БД Вас не интересуют. Вам бы плагины попрограммировать. Причем, зачем-то с использованием "медленной и идиотской" технологии:) Успехов, тем не менее:)

Arhat109Как писатель, добавлю для тех кто любит слышать только себя:
вот слова ТС:
...
Вы уже сами с собой начали разговаривать?:)
Arhat109Так вот, поскольку скорость выборки НЕ важна (читайте первый пост), запись быстрее чем в файл не сделает даже перехваленный mumps (тоже пишет в файл через ФС плюс накладняк), а уж размер хранения float в строковом виде превышает любой обсуждаемый размер (основной вопрос для ТС!), то mumps - не подходит .
Надеюсь, такое техническое обоснование - понятно, или "не по науке"?
Такое техническое обоснование говорит только о полном не знании mumps. Больше оно ни о чем не говорит. Вы сделали главным размер? Очень хорошо! Приведите размер БД в mumps и в любой другой БД. Я подчеркиваю - БД. Если Вы предлагаете БД не использовать (в этой сфере - "не БД" - как раз _мод специалист), то здесь я с Вами не поспорю, конечно. Я про "не БД" мало знаю:)

Arhat109Вот как раз ТАКИЕ Ваши ответы (и их тут полно и не только мне!) Я и называю демагогией. Далее пожалуйста, занимайтесь этим без моего участия. Ок?
Я и не сомневался, что Вам нечего сказать по существу из-за незнания технологий БД. Но не расстраивайтесь, у Вас еще все впереди. Причем, я уверен, что Вы только на словах игнорируете конкретные объяснения и советы, делая вид, что они Вам не понятны. Здесь многие имеют такую странную привычку:) А на самом деле, наверняка, многое поняли. И теперь Ваши заработки станут просто запредельными:)

Arhat109Бредятина, ровно настолько насколько нежно отношусь к фантазерам и теоретикам, настолько же тяжело реагирую на телепатов, которые любят делать выводы за счет своих способностей. Поэтому, не обижатесь на резкие выпады с моей стороны. У меня к Вам двойственное впечатление. Оставьте свои выводы об уровне моих знаний при себе. Мне - глубоко все-равно, что Вы на эту тему думаете.
Как говорил один мой коллега: "не пугайте меня клавиатурой! Я программировал когда их ещё не было".
Не оставлю, дружище:) Мне истина дороже.
1) Вы сказали про размер? Для данной конкретной задачи какой размер БД (предположим на 1 млн. записей) будет в mumps и других БД?
2) Вы проигнорировали drupal.
3) Вы не поняли, что mumps-плагин к MySQL - нелепая затея? А если поняли, почему не сказали?
4) Вы не ответили как храните данные в MySQL.
И у меня, вполне естественно, сложилось мнение о Ваших знаниях. Я бы оставил его при себе, если бы Вы оставляли при себе "демагогию":) Четыре (примерно из 12-ти) пунктов выше - это не демагогия:) А я с некоторых пор (здесь!) отвечаю адекватно. Вам может и все равно, а мне Ваши знания небезразличны, и я и дальше буду их повышать:) Стыдно не знать mumps, если занимаетесь БД. У меня тоже есть пробел, и мне тоже стыдно - плохо знаком с COBOL. Вот надо восполнять:)