Digital GodПросто про ... mumps я что-то в интернете мало чего нашел, поэтому смутно представляю что это.
http://blogerator.ru/page/nosql-vvedenie-v-teoriju-bd
Вполне достаточно для общего понимания.

Digital GodБредятина,
может стоит рассмотреть комбинированный вариант - типа mysql+mongo(couch и т.д.) или лучше не мудрить?
Мне кажется, здесь Вам уже объясняли все, в той или иной форме, что лучше не мудрить. Все уже намудрено до нас:)

Здесь еще можно послушать коммерческие аспекты:)
http://www.fisglobal.com/ClientSuccess/index.htm

guest_20040621Системой хранения хрен знает чего хрен знает как за совершенно запредельное бабло - это imho точнее.
Да, в точности как и Oracle:) Правда для разработчиков более мощный инструмент, чем Oracle, а бабло, все-таки, не более запредельное:)

Digital GodНаткнулся на форуме на hstore в Postgresql - может стоит в эту сторону посмотреть?
Народ пишет что на 10 млн записей работает быстро по сравнению с EAV.
В теории и практике БД стагнация. Давно. Народ может писать все, что угодно. Поскольку Вы намерены, все-таки, экспериментировать, смотрите во все стороны:) Если Вы хорошо знакомы с PostgreSQL, а в ней решили сделать что-то похожее на mumps (в Oracle, например, активно пытались реализовать некоторые свойства mumps в 8i), попробуйте PostgreSQL. Мне один из разработчиков этой СУБД сказал, что проблемы масштабирования неразрешимы, и они занимаются активно разработкой новой СУБД (для научных исследований).

guest_20040621> Да, в точности как и Oracle

Не сравнивайте кривой кусок окаменевшего дерьма и СУБД. Нет ни одного повода. Для вас и таких, как вы, специально создали загон - раздел форума. Вот там и обменивайтесь мнениями с... соратниками. Вменяемых людей оставьте в покое.
Механизм sql.ru работает без сбоев:) Мои ответы по существу модератор стал удалять. Поздравляю!
Повторю. Понятно, что Вы, на младшем курсе, еще можете не знать mumps. Но не знать Oracle - это странно. Ее здесь, кажется, все знают. То, что Oracle не является СУБД - доказанный факт. Для того чтобы управлять данными нужна семантическая зрелая модель и метаданные. Дейт очень точно сформулировал что нужна готовность к управлению данными, чтобы называться СУБД. Читайте:) И не уходите от обсуждения вопросов по существу просто в надежде на модератора, работу которого оплачивает та же Oracle:)

MasterZivOn 07/20/2012 10:22 PM, Бредятина wrote:

> в 8i), попробуйте PostgreSQL. Мне один из разработчиков этой СУБД сказал, что
> проблемы масштабирования неразрешимы, и они занимаются активно разработкой новой

А у меня в подполе -- барабашка.

Вас тоже модератор оберегает:) От обсуждения вопросов по существу. Поддерживая Вашу опять не конструктивную позицию. Я Вам факт, а Вы очередную барабашку:)

guest_20040621Бредятина, дружище, мне вас искренне жаль. Серьезно.
А уж как мне вас, студентов современных, жаль, даже не представляете:)

LSVБредятина. То, что Oracle не является СУБД - доказанный факт.Я так понял, по уровню гениальности и безапеляционности, товарисч Бредятина хочет нам похвастаться своей "настоящей СУБД" ? Ну дык милости просим. Заодно и посмеёмся...
Нет не понимаете, что характерно:) Будьте внимательнее, если искренне хотите разобраться в теории и практике БД. Не тратьте энергию на иронию бессмысленную:)
LSVКакое вообще отношение имеет тип СУБД к сабжу - реализации каталога товаров ?
Хорошая реализация сабжа не зависит от типа СУБД.
Что такое хорошая ? Портабельная, стандартная, простая и понятная.
Ошибаетесь, еще как зависит, и я это ясно объясняю, а Вы просто игнорируете, потому что БД Вас мало интересуют, вероятно:)

LSVБредятинаОшибаетесь, еще как зависит, и я это ясно объясняю, а Вы просто игнорируете, потому что БД Вас мало интересуют, вероятно:)Ну дык назовите нам настоящую СУБД !!! Где она ?
Почему до сих пор не покорила мир ?
Каше/НоСКЛ ? Смешно. Чисто словесный маркетинг в стиле свидетелей иеговы. :)
Не фантазируйте, пожалуйста. Вы процитировали изначально факт, что Oracle - не СУБД, и не нужно теперь переключаться на какие-то другие темы. Смешные или грустные:) Я все факты тщательно объясняю. Просто повнимательнее будьте, если Вас что-то интересует в области БД.
LSVЯ (и не только я) игнорирую высоколобые, безаргументные лозунги в стиле "продукты ХХХ, YYY, ZZZ - говно".
Это Вы к чему написали??? Я лозунгами не занимаюсь. Я все тщательно аргументирую. Но, Вы, видимо, не читатель, Вы - писатель. Лозунгов:)
LSVзы:
- Доктор, меня все игнорируют.
- Следующий !
(с)
Наконец-то, что-то попытались написать по существу. Но неверно. Многие не понимают суть концепции ключей. И Вы - не исключение, к сожалению:)

vadiminfo Вообще-то МУМС не во всех источниках фигурирует как СУБД. Иногда Иго просто относя к перманентным ЯП: может сохранять данные после завершения.
1) mumps не является СУБД. Это просто факт, и не нужно его никак интерпретировать. Так же, как и в случае с Oracle, чтобы управлять данными нужно программировать. Разумеется mumps (как язык) намного мощнее PL/SQL (то есть, в случае с Oracle программировать приходится не на одном языке), но, тем не менее, ни mmps, ни Oracle СУБД не являются.
2) mumps - это технология баз данных, включающая язык программирования, а вовсе не язык программирования. Точно так же, как и Oracle - это не язык программирования. Но и не технология БД, а просто продукт, ориентированный на реляционную технологию.
3) Не после завершения, а во время исполнения:)
vadiminfo Тут один МУМПСисит до мозга костей выдавал не однократно, что де мол МУМПС - это средство для разработки СУБД. Т.е. признал, что она не СУБД, а что-то типа С - который является в чстности "средством реализации" СУБД у более или менее нормальных производителей. Т.е. М просто ЯП.
На мой взгляд, это уже просто умышленное вранье, по другому не могу сказать. Для столь эрудированного человека приравнивать С к Oracle или mumps - не серьезно:) mumps, как ЯП, аналогов не имеет.
vadiminfo Каша - СУБД во всех источниках, но типа на основе МУМПСа.
И в Каше, чтобы она стала типа постреляционной, еще прикрутили типа ООМД и МНГОМЕРНУЮ МД, поскоку прикрутка тока SQL, скорее всего, позволяет претендовать не более че на реляционность.
Я бы на Вашем месте прекратил умышленное безграмотное использование терминов и названий продуктов. Это не несет никакой новой информации.
Cache - СУБД, созданная на mumps.
Никакой многомерности там никто не прикручивал. Возможно Вы имеете в виду реализацию технологии, которая была в Pick, в качестве дополнительной возможности.
Объекты (в смысле ООП, но не КОМД) в Cashe реализованы намного лучше, чем где-либо, но это естественно, так как полностью соответствует природе mumps.
mumps, как язык, был одним из первых, в который был стандартно интегрирован SQL - еще до появления Oracle:)

В свое время (27 лет назад) я проводил сравнительный анализ mumps и Oracle в плане возможностей создания СУБД. И mumps оказалась существенно гибче и перспективнее, что и подтвердилось на практике:)