Ron
деревья в nosql можно хранить т.к. в большинстве систем есть ключи, при этом основное преимущество в том, что подобные системы в отличие от реляционных не обладают четкой структурой.
А это означает, что у них должен хорошо работать поиск и обход неструктурированных данных. Вот почему хочется выбрать именно nosql. Т.е. есть возможность отойти от бесконечных join. Пример тому обход графовых баз данных и поиск по ним.
И хм может быть это, конечно, моя паранойя, но рано или поздно если мы говорим о каталоге, возможно понадобится переносить товары и связные сними, свойства комментарий системы оценок и прочее в архив, допустим на параллельный сервак служащий хранилищем. И как я понимаю сделать это будет проще гораздо, если все данные лежат в одном месте.
Т.е. в принципе если понадобится для одного товара можно создать одну "таблицу" и хранить данные в ней, а в последствии просто импортировать.

Я пересмотрел маленькую кучу мануалов по данным базам идеальным решением является redis, но проблема в том, что он создан для работы с оперативкой т.е. в целом он не рассматривается как хранилище для данных.

Графовые базы данных прекрасны в своей логике, но занимают слишком много места.

Те примеры которые скинул sergeiss, демонстрируют что в реляционках как и их антиподе происходит размазывание этих возможностей т.е. хранилища идут по пути развития общих решений. Вот и получается в итоге- почти любую базу можно подогнать под необходимое решение, вопрос лишь какую часть функционала придется дописывать на php. И какая база позволит решить большинство задач.

sergeiss
>К тому моменту, когда у тебя скопится такое гигантское хранилище инфы, ты накопишь ТАКОЙ опыт, что будешь нас тут учить, а не вопросы задавать smile.gif

вообще-то я думал, что ты предложишь решение опираясь на свой опыт))

>Чтобы совсем уйти от джойнов, нужно постоянно дублировать данные. Что несколько ускорит процесс выборки, но даст очень много минусов в другом.

да в потребляемых ресурсах и используемой памяти, в целом , как я понимаю, графовые базы это и есть решение использующее аналоги множества джойнов

hurt3, ты хорошо прочел статью, я тебе ссылку давал? =) Заголовок громковат, но статья толковая.

Ron

да она бред пишет, вдумайся в то, что она там понаписала, ты бы сам стал так работать?

это знаешь на уровне экспериментов студента первого курса, программист такой...

такую архитектуру придумать для бд да еще об этом рассказать, не позорилась бы лучше

ну если не веришь мне посмотри отзывы под статьей

Реляционные базы стремятся к фичам nosql баз, а nosql базы стремятся к фичам реляционных. Наступит день, можно будет закрыть глаза и случайно тыкнуть пальцем, делая выбор СУБД. И, да, попадешь в Постгре.

Однако этот прекрасный день еще не наступил, поэтому связка реляционной базы (которая в нормальной форме хранит данные) и nosql-решения (в которое дублируются данные в том виде, в котором по ним будет удобно искать) сегодня выглядит достаточно разумным решением.

Реляционная СУБД - Постгре. Не думай, не спорь, забудь про Мускул, юзай Постгре.

Nosql - здесь сложнее. Подумай, чего будет больше (записей или выборок), насколько много данных там будет храниться, и какие конкретно фичи понадобятся. Ужесточай требования к базе (в плане фич на развитие, например) - и у тебя останется список из одного продукта, его и используй.

neadekvat


название любимой Nosql в студию

аналог редис но не как системы для использования оперативки есть?

да почитал про пострег не понимаю почему сms и мануалы делают упор на mysql

hurt3, я на mongo. Только тебе надо внимательно посмотреть, что там с полнотекстовым поиском - в последней версии, кажется, что-то допиливали, но надо смотреть, что именно.

neadekvat
ну да монго сейчас и юзаю

Ron
)
парни, а где почитать про обустройство этого форума?

sergeiss

подскажи плиз книгу по постгре желательно русского автора

Ron, лично мое мнение, что целостность должна обеспечиваться протестированным кодом и логированием. То есть на самих базах никакие лишние ограничения вешать не стоит.

Кроме того, выше я описал решение, в котором есть основная база и дублирующая. Где дублирующая - nosql, в которой мы складываем данные в денормализованном виде и вообще так, как нам удобнее их доставать (а не контролировать). Иначе говоря, есть база (основная), в которой данные остаются 101% (бэкапы, реплика и т.д.), и есть вторая база, которую мы можем дропнуть и быстро восстановить все значения из основной базы. В угоду простоте и быстродействия мы допускаем шанс того, что какие-то данные в ходе работы не попадут из основной базы в дублирующую, но в конечном итоге нам выгоднее жить с таким шансом, чем городить кучу неподдерживаемого кода (в т.ч. на уровне бд).