krvsasigmovВот почему всех кто юзает Cache' посещают идеи реализовать что-то уродское....
Не всех.

Отчасти это связано с тем, что можно вообще придумывать любые NoSQL хранения? Чего напроч лишены другие разработчики с "табличным" хранением данных...

Вообще-то, нормальные разработчики сами выбирают СУБД под задачу. Не подходит SQL-БД для хранения сессий - возьмёт Redis. Нужно хранить JSON-документы с поиском по полям - MongoDB или CouchDB. XML-документы - Sedna. Нужно хранить объекты - Cache' или реляционка с ORM. Нужны разнообразные отчёты - опять-таки "табличное" хранение данных.

Хреново, когда одну и ту же СУБД пытаются пихать везде, пытаясь придумать любые NoSQL, SQL и прочие хранения. И, если приходится реализовывать что-то уродское на Cache', наверное стоит задуматься, нафига каше вообще здесь нужна?

Бредятинане рубящий в кашеВообще-то, нормальные разработчики сами выбирают СУБД под задачу.
Заблуждение. Часто (мягко говоря) у заказчика уже есть СХОД (СУБД - это вряд ли), и задачу нужно решить именно в ней. И уж совсем невероятно, чтобы заказчик вкладывал средства в разработку СУБД))

Здравствуйте, ЧАЛ! Если у заказчика стоит СХОД(СУБД и проч.), о которой вы рассуждаете, скорее всего этот заказчик - не наш клиент. Тем более, я писал о проектировании , а не о, мягко говоря, доработке.

Бредятинане рубящий в кашеНе подходит SQL-БД для хранения сессий - возьмёт Redis. Нужно хранить JSON-документы с поиском по полям - MongoDB или CouchDB. XML-документы - Sedna. Нужно хранить объекты - Cache' или реляционка с ORM. Нужны разнообразные отчёты - опять-таки "табличное" хранение данных.
Заблуждение. Разработчику не могут быть нужны какие-либо предопределенные структуры данных. Они могут быть прописаны в ТЗ - это бывает.

Прошу от вас ТЗ с такой конкретикой. Вряд ли дождусь, зная вашу активность по форуму. Потому что только разработчику и знать о структурах данных, с которыми он будет иметь дело. Это дело разработчика, ему и планировать предметную область, ему и думать о хранении в СУБД (у вас своё мнение о том, что является СУБД, просто предупреждаю).
Бредятинане рубящий в кашеХреново, когда одну и ту же СУБД пытаются пихать везде, пытаясь придумать любые NoSQL, SQL и прочие хранения.
Может быть. В IS этого и не делают. Хранят банально в базовой архитектуре))


Какая базовая архитектура у IS? Что это вообще такое? Жду ответа в этой ветке форума, а не ссылок. Именно ответов, а не разглагольстований о том, что такое архитектура, что такое базовая, и проч. Кстати, очень интересно, что вы понимаете под словом "архитектура".
Бредятинане рубящий в кашеИ, если приходится реализовывать что-то уродское на Cache', наверное стоит задуматься, нафига каше вообще здесь нужна?

Поскольку в Cache имеется уникальная базовая технология для решения информационно-логических задач, то есть, для разработки приложений БД без использования СУБД, то здесь Вы правы - в философском смысле, никакие другие системы, конечно, не нужны. Но, с естественными монополиями нужно как-то бороться))...
А тема, наряду с
http://www.sql.ru/forum/actualthread.aspx?tid=1012388
полезная))
Уникальная базовая технология - что вы имеете в виду? Мне честно, очень интерестно.

krvsaне рубящий в кашеВообще-то, нормальные разработчики сами выбирают СУБД под задачу.
Только где их взять?


Откройте для себя гугл. Или яндекс.
krvsaне рубящий в кашеИ, если приходится реализовывать что-то уродское на Cache', наверное стоит задуматься, нафига каше вообще здесь нужна?
Или перестать реализовывать это уродство...
Согласен.

Бредятинане рубящий в кашеЗдравствуйте, ЧАЛ! Если у заказчика стоит СХОД(СУБД и проч.), о которой вы рассуждаете,
Это ошибка. Надеюсь, не умышленная. Я ни о какой СХОД (СУБД и проч.) не рассуждаю.
ok.
Бредятинане рубящий в кашескорее всего этот заказчик - не наш клиент.
Мне о Ваших клиентах ничего не известно. Не стоит развивать эту мысль, и все дальше уходить от темы в сторону характеристик Ваших заказчиков.
ok. Я говорил о том, что если у заказчика стоит не известная мне СУБД, я бы не рискнул с ней связываться.
Бредятинане рубящий в кашеТем более, я писал о проектировании , а не о, мягко говоря, доработке.
Серьезная ошибка - Вы не писали о проектировании, а вот только сейчас об этом написали. И еще более серьезное заблуждение - и доработка, и разработка, конечно же, предполагают проектирование, и даже перепроектирование))

Серьезная ошибка, что для вас выбор СУБД не явлется проектированием.
Бредятинане рубящий в кашеПрошу от вас ТЗ с такой конкретикой. Вряд ли дождусь, зная вашу активность по форуму.
В этой теме рассматривается ТЗ с такой конкретикой)) Так что уже дождались, даж до моего ответа))

Мой ответ был изначально адресован krvsa. И если вы удосужетесь прочитать-таки эту тему, то поймёте, что проблема в структуре БД. (И зачем я опять поднял эту тему?)
Бредятинане рубящий в кашеПотому что только разработчику и знать о структурах данных, с которыми он будет иметь дело. Это дело разработчика, ему и планировать предметную область, ему и думать о хранении в СУБД (у вас своё мнение о том, что является СУБД, просто предупреждаю).
Серьезные заблуждения. И главное из них - я здесь свои мнения не высказываю. Только устоявшиеся чужие.

Без комментариев, ЧАЛ.
Бредятинане рубящий в кашеКакая базовая архитектура у IS? Что это вообще такое? Жду ответа в этой ветке форума, а не ссылок.
По вежливее, пожалуйста)) Это не учебный портал. Но, в этом разделе есть тема, кажется "Вопросы новичков". Задайте там вопросы, если Вы еще не разобрались в технологии.

ok. Сложно с вами дискутировать. Напишите мне ещё про Дейта. И Кодда не забудьте добавить. Хотя, да, гораздо лучше послать собеседника никуда.
Бредятинане рубящий в кашеИменно ответов, а не разглагольстований о том, что такое архитектура, что такое базовая, и проч. Кстати, очень интересно, что вы понимаете под словом "архитектура".
А мне уже давно не интересно. Поэтому обойдусь без разглагольствований))
ok.
Бредятинане рубящий в кашеУникальная базовая технология - что вы имеете в виду? Мне честно, очень интерестно.
Я имею в виду хорошо всем известную базовую технологию. А так же я имею в виду. что Вам это совершенно не интересно. ok. Очередной слив.

doublefintне рубящий в кашеВообще-то, нормальные разработчики сами выбирают СУБД под задачу. Не подходит SQL-БД для хранения сессий - возьмёт Redis. Нужно хранить JSON-документы с поиском по полям - MongoDB или CouchDB. XML-документы - Sedna. Нужно хранить объекты - Cache' или реляционка с ORM. Нужны разнообразные отчёты - опять-таки "табличное" хранение данных.
Вы же читали это или перевод ?

Да, читал. Тем более, взял от Твида маппинг JSON-структур. Но я всё же придерживаюсь мнения, что для каждой задачи должно быть своё, удобное решение.
Ведь согласитесь, что для реляционного хранилища лучше использовать СУБД, которая сама построит для вас индексы и позаботится о производительности ваших SQL-запросов. И для хранения JSON'а лучше взять ту СУБД, что потом позволит искать по нему. Без последующих забот об индексах в глобалах и прочего.

krvsaне рубящий в кашеОткройте для себя гугл. Или яндекс.
Это там ищут работников?
А тех, что есть отправить обратно в Гугл и Яндекс?

Вам бы всё себя подороже продать... :))

rongo, Прошу прощение за превращение и этой темы в адовый оффтопик.