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, Прошу прощение за превращение и этой темы в адовый оффтопик.

krvsaне рубящий в кашеВам бы всё себя подороже продать... :))
У вас обратное желание?

Нет, я уверен, что вы отличный специалист, стоящий своих денег. Я это увидел по вашим хорошим постам в этом форуме. Просто вас выдает желание переехать в нерезиновую, или на канары(допустим), как я так же понял по постам. :)

Шваров Евгенийне рубящий в кашеДа, читал. Тем более, взял от Твида маппинг JSON-структур.

А что за маппинг JSON-структур? Не хотите статью написать о применении? Думаю многим будет интересно.

Моя поделка тут: https://github.com/agsh/boobst Не думаю, что она стоит серъёзного внимания, но от pull-request'ов и свежей крови я бы не отказался.

DAiMorне рубящий в кашепропущено...

Моя поделка тут: https://github.com/agsh/boobst Не думаю, что она стоит серъёзного внимания, но от pull-request'ов и свежей крови я бы не отказался.интересная штука, только есть несколько но:
для Node.js IS уже как минимум с 2012 версии есть свой адаптер, без необходимости поднимать свой TCP сервер в Cache.
И по-моему для работы с Mumps-СУБД, было бы логичней сделать ORM обертку

Да, сама идея повторения того, что уже есть и выеденого яйца не стоила, но я хотел повторить функциональность Weblink'а. А для этого мне нужна была возможность запускать рутины и получать в node.js то, что каше шлёт в stdout. Этого в драйвере для GlobalsDB нет (я смотрел на него, а не на драйвер для Cache'). Так что пришлось идти тем же путём, что и Твид, и Каратаев.
Причём, у Твида уже был MWire под node.js для MUMPS, но он базируется на текстовом протоколе для Redis и не потходит для передачи бинарных данных, что было нужно мне.
Такие дела, пришлось ваять своё поделие. Со стороны node.js выглядит сностно, со стороны Cache' - не очень.
ORM-обёртка вряд ли, ведь работа идёт напрямую с глобалами, а там у Cache' суровая проекция, в которую я не врублюсь никогда наверное, а вот ODM, как в монге, возможна.

Бредятина, давайте жить дружно. Я уже не понимаю, о чём мы с вами ведём диалог. Я к этому привык. Давайте его закончим.

DAiMorне рубящий в кашеORM-обёртка вряд ли, ведь работа идёт напрямую с глобалами, а там у Cache' суровая проекция, в которую я не врублюсь никогда наверное, а вот ODM, как в монге, возможна.В любом случае я имел ввиду попытку реализовать именно объектную модель, например что-то похожее есть при использовании Java-проекции. Сам я с Node.JS так же сталкивался только при работе с Globals на конкурсе по GlobalsDB и делал свои конкурсные работы как раз на Node.js, отчасти чтобы пощупать и то-то. И у самого приходила идея реализации нормальной объектной модели но как-то по времени не сошелся, и необходимости пока не возникало.
какая реализация на Node.js для Cache я не знаю, не смотрел и насколько она отличается от решения от GlobalsDB, но думаю если там возможна привязка к объектам Cache и вызов методов объектов и классов, то вполне можно обойтись и этим.
а вот реализаций с другими субд вообще не знаю, нет времени заниматься ничем другим, только Cache.
Ну, просто сохранить объект в моей поделке легко:


Или вместо функции set использовать saveObject.

Только вот получить его - проблема, но я работаю над этим :) И сделать ODM с прототипным наследованием, как в mongoose, я пока не решился.

DAiMorне рубящий в кашеORM-обёртка вряд ли, ведь работа идёт напрямую с глобалами, а там у Cache' суровая проекция, в которую я не врублюсь никогда наверное, а вот ODM, как в монге, возможна.В любом случае я имел ввиду попытку реализовать именно объектную модель, например что-то похожее есть при использовании Java-проекции. Сам я с Node.JS так же сталкивался только при работе с Globals на конкурсе по GlobalsDB и делал свои конкурсные работы как раз на Node.js, отчасти чтобы пощупать и то-то. И у самого приходила идея реализации нормальной объектной модели но как-то по времени не сошелся, и необходимости пока не возникало.
какая реализация на Node.js для Cache я не знаю, не смотрел и насколько она отличается от решения от GlobalsDB, но думаю если там возможна привязка к объектам Cache и вызов методов объектов и классов, то вполне можно обойтись и этим.
а вот реализаций с другими субд вообще не знаю, нет времени заниматься ничем другим, только Cache.

Провафлил, не увидел ваши ремарки про методы объектов, классы и прочее. Нет, я такой возможности в node.js не вижу. Учитывая различия в понимании и реализации объектной модели в языках javascript и cache object script, считаю такое невозможным в принципе. В случае работы с серверным джаваскриптом, дальше реализации mongoose под Cache' дальше пойти не получится.