Каморка

Папа Карло,

мона я буду отвечать ему?

а не подеритесь!

Жооожииик. Ты где?

vg писал(а):Жооожииик. Ты где?

АбажжЫ чуток, не до тебя пока
Ты книжку почитай пока, про то что такое классы, наследование, инкапсуляция и т.д.

Жожик,

классы, наследование, инкапсуляция

Ты чё, то же на жабе програмируешь, и ругаешься непонятными для меня ругательствами? Не называй больше меня инкапсуляцией. А то приеду и .....

ПС.
Кошмар какой-то с этими Канадцами. То я синофанта, то у меня сифилис, как " ....у всех на корабле...". Теперь вот ещё и инкапсуляция. Это что? Хайтек-презерватив что ли ?

george писал(а): ЗЫ Папа Карло, вот мне стало интересно, как не плодить поля или таблицы? Поделись, а?

одна таблица со списком обьектов и одна со значениями теоритечески может заменить все таблицы вообще.

Проблема не в этом, а в производительности.

А на поднятые вопросы Гари так никто не ответил по существу, кроме рекламных приграшений сходить на сайт информикса.

да, кстати, насчет РАО ЕС.
Учитывая что тендера и скоп-проектирования скорее всего не было, то вполне напрашивается мысль, что тот кто затеял эту кашу с кэшем на РАО другого на данный момент и не знал.

--Главным аргументом в пользу Cache оказалась скорость. из причин высокой скорости Cachе является ее способность кэшировать часто выполняемые операции. .. По словам Стерба, департамент также рассматривал другие СУБД, но ни в одной из них не оказалось подобных функций.

а про пулинг в реляционных ОС и даже ODBC видно товарищи ничего не знали.

2Lepsik,

одна таблица со списком обьектов и одна со значениями теоритечески может заменить все таблицы вообще.
Проблема не в этом, а в производительности.

Ты прав. Так не получится. Я говорил об этом чуть выше. Но ты не прав в том, что только там можно сделать.

а про пулинг в реляционных ОС и даже ODBC видно товарищи ничего не знали.

Не умничай. Здесь словов-то таких не знают.

vg,
я знаешь чего надумал, посоветомшись, правда, с умными людЯми... я таки не буду отвечать. Дело в том, что мы с тобой будем разговаривать как китаец с французом, каждый на своем языке, и знаешь чего из этого выйдет? Прально, ничего... (кстати, общение с п.Карло в привате именно это и показало). Мы слишком разные... Я уже не помню реляционных БД, хотя когда-то в них работал, очень давно, правда... Типа в DBase, FoxBase, Access... Ты, скорее всего, никогда не работал в ООБД. Возможно, что в Оракле и т.п. M$ SQL Server-е я что-то не догоняю, хотя общался и с гуру в этих делах, и из этого общения вынес, что хранение данных в реляционных БД сводится таки к нормализации и хранению в плоских таблицах (даже в случае реализации ООП), а в Cache' ты сам определяешь стратегию хранения, как хочешь, используя многомерный сервер данных (или пользуешься стандартной, it's up to you). Твои "обычные объектные надстройки" над РСУБД притянуты туда за уши, а здесь программер работает с объектами изначально, причем из чего бы ни работал - их C++, VB, Java, Delphi, или пользуя внутренние языки - Cache' ObjectScript либо Cache'Basic...
Хранение объектов в РСУБД знаешь с чем сравнивают? Это как хранить автомобиль, разбирая его каждый раз в конце дня по запчастям, а утром собирая обратно Мягко говоря - неэффективно
Ладно, vg, я умолкаю, чтобы не продолжать разговор на разных языках...
Я ничем не хочу обидеть реляционных предшественников, более того, наверное, там, где бизнес-логика проста, пользователей немного, денег много, затраты не считают, задача не требует объектной реализации, то там имеет смысл пользоваться плоскотабличными парадигмами.
Время покажет, и все расставит на свои места...

george писал(а):хранение данных в реляционных БД сводится таки к нормализации и хранению в плоских таблицах Хранение объектов в РСУБД знаешь с чем сравнивают? Это как хранить автомобиль, разбирая его каждый раз в конце дня по запчастям, а утром собирая обратно Мягко говоря - неэффективно
Ладно, vg, я умолкаю, чтобы не продолжать разговор на разных

Видишь ли оченно много на свете гуру баз данных которы та ки да считают что база должна быть нормализована ваще всегда. Что естесвенно не так. Как тот мальчик с молотком. У меня напрмер база денормализована частично. Вообще нормализация изготовлена для уменьшения размера носителя данных и увеличения производительности операций изменений/добавлений. Для чиста ОЛТП систем норамлизация полезна. Склады данных простроены несколько по другому. А вот самое интересное - это когда система выполняет обе функции одновременно. Плюс некторые клиенты регулярно просят денормализовать их нюю базу бо пваять отчтеты в критсалльных отчетах им тяжело. Типа три таблицы он могут еще соединить, а больше трех - пиндец полный.

Про автомобиль пример клаасный но неправильный. Лично я буду хранить автомобиль целиком даже ежели это супротив третьей нормальной формы или какой там положено? Хотя да до хрена деятеолей коорые его таки разберут до винтика. Некторые клиенты на нас наехали пару раз и сказали что они хотят нормализованную базу. Ну ежели для нормализованная база - это конечная цель, то нет проблем. Сваяли как положено в книжке. Нам полностью пофиг за что бабки получать. Ежели завтра клиент скажет что хочет ваять на это Каше - бум ваять на Каше. Не просят. Просят Оракл, Мелкомягкий, Информикс.

2george,

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

1) Ну, с умными, так с умными. Да, прости ты нас дураков .
2) «Не буду отвечать…..» Дык ведь ответил же

Дело в том, что мы с тобой будем разговаривать как китаец с французом, каждый на своем языке, и знаешь чего из этого выйдет? Прально, ничего... (кстати, общение с п.Карло в привате именно это и показало). Мы слишком разные...

Это точно. Именно поэтому я и задаю вопросы. Если иногда в язвительной форме, - так чего обижаться-то на дурачков? А посмотри, как меня здесь «колбасят». И что из этого?

На самом деле после нескольких месяцев общения на форуме у меня сложилось впечатление, что если не Россия, то уж её отдалённые регионы точно – отсталая, дремучая страна в IT. Мне, например, даже на уровне терминологии часто трудно разобраться, о чём речь.

Теперь немного яда:

кстати, общение с п.Карло в привате именно это и показало

Просто совет. Не прикрывайся любым приватом. Отвечай сам за себя. Ну, и, кроме того, если уж пишешь кому либо в приват, то незачем об этом трубить на весь форум. Без обид.

Типа в DBase, FoxBase, Access... Ты, скорее всего, никогда не работал в ООБД. Возможно, что в Оракле и т.п. M$ SQL Server-е я что-то не догоняю,

Ты прав. Я никогда не работал с «настоящими» ООДБ. Хотя, если честно – то я вообще не очень-то здесь верю в «настоящее», гуру и авторитетам (за исключением Лепсика, Папы Карлы и Мармота, естественно)
Отсюда и мои вопросы были тебе. Всё знать невозможно. Могу сказать ещё больше о себе. Я ещё меньше, похоже, знаю здесь, чем ты. Из того набора, что ты пропостил – Оракл надо вычеркнуть для моей персоны.

хотя общался и с гуру в этих делах, и из этого общения вынес, что хранение данных в реляционных БД сводится таки к нормализации и хранению в плоских таблицах (даже в случае реализации ООП),

1) То были не те гуру, или ты не то «вынес». Те определения, что выше, если уж говорить, что к чему сводится – суррогат. Очень примитивный взгляд. Имхо, конечно.

2) Я действительно не знаю, как организованны данные в «настоящих» OODB. Но исходя из моих безусловно скромных познаний в IT, и из того, что чудес не бывает, возьму на себя смелость сказать, что никакого персистентного представления объектов (объектов - в поведенческом смысле) не существует вообще. В конечном случае – всё храниться «плоско». Плоская модель памяти и её обработки - у современных компьютеров. Всё адресуется в примитивном линейном адресном пространстве. И там нет места для объектов. Объектное представление в программировании это только плод фонтазии программиста. Да и то, только на стадии компиляции. В ран-тайме не существует никаких объектов. Здесь, я не хочу ни в коем случае переводить тему в другое русло, спорить о том, что один из подходов (например, «компонентное программирование») объектнее или персистентскее другого. Но думаю, что и в «настоящих» ООБД – всё храниться весьма плоско в конечном счёте. Выпуклость и впуклость существует, только тогда, когда ты при помощи неких скриптовых, визардовых средств описываешь сущности с использованием парадигм, близких тем, что приняты в ООП.

а в Cache' ты сам определяешь стратегию хранения, как хочешь, используя многомерный сервер данных (или пользуешься стандартной, it's up to you).

Вот поэтому я и спрашивал тебя о тех абстрациях, которые доступны в Cache. И здесь ты, к сожалению, ничего не ответил. Это интересно для меня было на самом деле.

Твои "обычные объектные надстройки" над РСУБД притянуты туда за уши, а здесь программер работает с объектами изначально, причем из чего бы ни работал - их C++, VB, Java, Delphi, или пользуя внутренние языки - Cache' ObjectScript либо Cache'Basic...

Воспринимаю это в качестве твоих эмоций. Только три замечания.

1) Во-первых откуда ты знаешь о масштабах решаемых мною задач. Может эти масштабы таковы, что как раз объектной надстройки – достаточно. Есть конкретная задача, конкретный инструмент, конкретный результат. Я и не склонен обобщать ЭТО на другие задачи. Универсальных технологий не существует вовсе. Не бывает «коробочек», которые спасут мир.

2) Сильно по своей неграмотности подозреваю, даже не зная как работает Cache, что от так и поступает -

«…в конце дня по запчастям, а утром собирая обратно…»

Если это не так, то возможно, что это весьма неэффективное «избыточное» объектное представление, принятое, например, в Geodatabase ArcGis (продукт компании ESRI).

3)

«…притянуты туда за уши…»

этим я баловался давно, когда писал диссертацию. Уже давно переболел и выздоровел. Когда работаешь на производстве, то с тебя спрашивают результат.

Ладно, vg, я умолкаю, чтобы не продолжать разговор на разных языках...

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

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

Не будь ребёнком. Обидеть – не обидеть. Прям красна девица.

ПС. Ваще мне всё не пофиг

2Володя,

Видишь ли оченно много на свете гуру баз данных которы та ки да считают что база должна быть нормализована ваще всегда.

Просто эти люди занимаются задачками, кроме которых ничего больше не видели.

У меня напрмер база денормализована частично.

Часто это правильно, если мы за чистоту результата, а не идей и постулатов.

Вообще нормализация изготовлена для уменьшения размера носителя данных и увеличения производительности операций изменений/добавлений.

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

Хотя да до хрена деятеолей коорые его таки разберут до винтика.

Такой подход никто в практике не использует. Приведите примеры.