|
Какую БД выбрать для товарной базы?
|
|||
---|---|---|---|
#18+
Arhat109, Хм. Ваша задача очень похожа на Яндекс.Маркет. Насколько мне известно, там используются обычные БД, чуть ли не MySQL. Нагрузка там - сами представляете, какая :) Так что проблема не в БД, а в чем-то еще. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2011, 18:18 |
|
Какую БД выбрать для товарной базы?
|
|||
---|---|---|---|
#18+
Arhat109, И что-то мне говорит, что вы решаете слишком общую задачу. Если разговор про склады, то там есть категории (отдельная сущность), товары (возможно, в виде комплектов, уровень вложенности ну точно не больше двух), атрибуты (для товаров и элементов). Придумать структуру таблиц и индексов, которая покрывает все разумные требования - можно. Работать будет быстро. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2011, 18:39 |
|
Какую БД выбрать для товарной базы?
|
|||
---|---|---|---|
#18+
DPH3, Да, Вы правы. Совсем "общую". Уже лет 10 и не один. Есть ещё один фанатик. :) Маркет у Яндекса - слишком примитивен, а именно: в нем нет рекурсии. Поэтому и можно решать реляционными методами. Задача склада, как правило локальна. И тут можно упростить архитектуру описаний до уровня простых зависимостей "категория"- "товар" - "наличие" - "цена" - "сроки". Примерно в похожем направлении движутся люди из Ноолаб кажется, у нас в городе. Но я уже давно не видел их отчетов и реляционными БД там явно "не пахнет". Они больше языковыми проблемами занимаются. Поищите что-нибудь по ключу "тема-рематический разбор текста" в Сети. С точки зрения идей построения архитектуры - оно "очень похоже". Собственно вопрос сужается до простого: быстрое и компактное хранение данных, которые приходится выбирать рекурсивно из простых реляционных моделей. Желательно, чтобы скорость выборки НЕ зависела от объема данных... а ещё лучше: и не сильно (лучше чем линейно) от глубины рекурсии. ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2011, 21:50 |
|
Какую БД выбрать для товарной базы?
|
|||
---|---|---|---|
#18+
akalend, пасибки. Стало понятнее. А ещё вопросик, можна? Не очень понял два момента: 1. организация рекурсивных связей. В качестве value надо использовать id другого "объекта", так? Соответственно "тип" или таблицу, или как она там у них называется, надо прописать еще одним value, так? Или есть какой-то ещё способ... 2. отслеживание внешних ссылок в таких случаях - полностью на "плечах разработчика" или нет? То есть меня интересуют вопросы "целостности" данных... уровень типа MyISAM? В принципе "не страшно". Но как это скажется на производительности? Так по моему опыту, реализация тотального контроля связей на исамовском движке в результате оказывается медленнее иннодбшного. То есть выигрыш - достаточно призрачен и хорош только когда тотальный контроль заведомо не требуется. Ну и третий вопрос: можно ли хранить value без имени - подозреваю что нет. То есть для "безимянных" значений надо будет использовать "тайное" имя. Так? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2011, 22:02 |
|
Какую БД выбрать для товарной базы?
|
|||
---|---|---|---|
#18+
Arhat109, Кажется наступило прозрение. :) На МонгоДБ и Мумпс - рекурсия похоже не требуется. Тему можно закрывать, Буду пробовать и там и там. По крайней мере получу 3 варианта для сравнения (MySql, mumps, MongoDB). Всем спасибки. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.04.2011, 14:34 |
|
Какую БД выбрать для товарной базы?
|
|||
---|---|---|---|
#18+
Arhat109DPH3, Да, Вы правы. Совсем "общую". Уже лет 10 и не один. Есть ещё один фанатик. :) За 10 лет можно было и свое хранилище попробовать написать. Если уж действительно требуется именно такая задача. Маркет у Яндекса - слишком примитивен, а именно: в нем нет рекурсии. Поэтому и можно решать реляционными методами. Ну, вообще-то, там есть рекурсия. Только ограниченной вложенности. Просто потому, что больша - не требуется. Примерно в похожем направлении движутся люди из Ноолаб кажется, у нас в городе. Но я уже давно не видел их отчетов и реляционными БД там явно "не пахнет". Они больше языковыми проблемами занимаются. Поищите что-нибудь по ключу "тема-рематический разбор текста" в Сети. С точки зрения идей построения архитектуры - оно "очень похоже". Хм, сайт Ноолаба не отвечает, других ссылок по теме не заметно. Собственно вопрос сужается до простого: быстрое и компактное хранение данных, которые приходится выбирать рекурсивно из простых реляционных моделей. Желательно, чтобы скорость выборки НЕ зависела от объема данных... а ещё лучше: и не сильно (лучше чем линейно) от глубины рекурсии. ;) Хм. Вообще-то, любую рекурсию можно развернуть в цикл. Может, если это сделать - то будет проще? И, конечно, "не зависимость от объема данных" - это теоретически невозможно. Если развернуть, то может быть получиться сделать логарифм от произведения объема на глубину - это может быть и лучше, чем линейно :) А вообще, в современных БД есть куча инструментов для работы с деревьями и рекурсиями. Просто не надо смотреть на MySQL - у этого сервера довольно узкое применение, для указанных задач совершенно не подходящее... ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2011, 22:40 |
|
|
start [/forum/topic.php?fid=48&msg=37238923&tid=1857013]: |
0ms |
get settings: |
25ms |
get forum list: |
26ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
55ms |
get topic data: |
15ms |
get forum data: |
3ms |
get page messages: |
186ms |
get tp. blocked users: |
2ms |
others: | 318ms |
total: | 638ms |
0 / 0 |