Папа Карло,
мона я буду отвечать ему?
Объектные БД
Правила форума
Пожалуйста, ознакомьтесь с правилами данного форума
Пожалуйста, ознакомьтесь с правилами данного форума
-
- Маньяк
- Сообщения: 2803
- Зарегистрирован: 29 май 2003, 22:29
- Откуда: Магадан - Миссиссага
- папа Карло
- Шарманщик
- Сообщения: 8563
- Зарегистрирован: 17 фев 2003, 15:04
- Откуда: НН -> BC -> WA -> UT -> CA
-
- Маньяк
- Сообщения: 2803
- Зарегистрирован: 29 май 2003, 22:29
- Откуда: Магадан - Миссиссага
- george
- Графоман
- Сообщения: 14127
- Зарегистрирован: 20 июл 2003, 12:48
- Откуда: M2R
-
- Маньяк
- Сообщения: 2803
- Зарегистрирован: 29 май 2003, 22:29
- Откуда: Магадан - Миссиссага
Жожик,
ПС.
Кошмар какой-то с этими Канадцами. То я синофанта, то у меня сифилис, как " ....у всех на корабле...". Теперь вот ещё и инкапсуляция. Это что? Хайтек-презерватив что ли ?
Ты чё, то же на жабе програмируешь, и ругаешься непонятными для меня ругательствами? Не называй больше меня инкапсуляцией. А то приеду и .....классы, наследование, инкапсуляция
ПС.
Кошмар какой-то с этими Канадцами. То я синофанта, то у меня сифилис, как " ....у всех на корабле...". Теперь вот ещё и инкапсуляция. Это что? Хайтек-презерватив что ли ?
- Lepsik
- Житель
- Сообщения: 522
- Зарегистрирован: 17 фев 2003, 18:34
- Откуда: Berlin
- Контактная информация:
одна таблица со списком обьектов и одна со значениями теоритечески может заменить все таблицы вообще.george писал(а): ЗЫ Папа Карло, вот мне стало интересно, как не плодить поля или таблицы? Поделись, а?
Проблема не в этом, а в производительности.
А на поднятые вопросы Гари так никто не ответил по существу, кроме рекламных приграшений сходить на сайт информикса.
да, кстати, насчет РАО ЕС.
Учитывая что тендера и скоп-проектирования скорее всего не было, то вполне напрашивается мысль, что тот кто затеял эту кашу с кэшем на РАО другого на данный момент и не знал.
--Главным аргументом в пользу Cache оказалась скорость. из причин высокой скорости Cachе является ее способность кэшировать часто выполняемые операции. .. По словам Стерба, департамент также рассматривал другие СУБД, но ни в одной из них не оказалось подобных функций.
а про пулинг в реляционных ОС и даже ODBC видно товарищи ничего не знали.
-
- Маньяк
- Сообщения: 2803
- Зарегистрирован: 29 май 2003, 22:29
- Откуда: Магадан - Миссиссага
2Lepsik,
Ты прав. Так не получится. Я говорил об этом чуть выше. Но ты не прав в том, что только там можно сделать.одна таблица со списком обьектов и одна со значениями теоритечески может заменить все таблицы вообще.
Проблема не в этом, а в производительности.
Не умничай. Здесь словов-то таких не знают.а про пулинг в реляционных ОС и даже ODBC видно товарищи ничего не знали.
- george
- Графоман
- Сообщения: 14127
- Зарегистрирован: 20 июл 2003, 12:48
- Откуда: M2R
vg,
я знаешь чего надумал, посоветомшись, правда, с умными людЯми... я таки не буду отвечать. Дело в том, что мы с тобой будем разговаривать как китаец с французом, каждый на своем языке, и знаешь чего из этого выйдет? Прально, ничего... (кстати, общение с п.Карло в привате именно это и показало). Мы слишком разные... Я уже не помню реляционных БД, хотя когда-то в них работал, очень давно, правда... Типа в DBase, FoxBase, Access... Ты, скорее всего, никогда не работал в ООБД. Возможно, что в Оракле и т.п. M$ SQL Server-е я что-то не догоняю, хотя общался и с гуру в этих делах, и из этого общения вынес, что хранение данных в реляционных БД сводится таки к нормализации и хранению в плоских таблицах (даже в случае реализации ООП), а в Cache' ты сам определяешь стратегию хранения, как хочешь, используя многомерный сервер данных (или пользуешься стандартной, it's up to you). Твои "обычные объектные надстройки" над РСУБД притянуты туда за уши, а здесь программер работает с объектами изначально, причем из чего бы ни работал - их C++, VB, Java, Delphi, или пользуя внутренние языки - Cache' ObjectScript либо Cache'Basic...
Хранение объектов в РСУБД знаешь с чем сравнивают? Это как хранить автомобиль, разбирая его каждый раз в конце дня по запчастям, а утром собирая обратно Мягко говоря - неэффективно
Ладно, vg, я умолкаю, чтобы не продолжать разговор на разных языках...
Я ничем не хочу обидеть реляционных предшественников, более того, наверное, там, где бизнес-логика проста, пользователей немного, денег много, затраты не считают, задача не требует объектной реализации, то там имеет смысл пользоваться плоскотабличными парадигмами.
Время покажет, и все расставит на свои места...
я знаешь чего надумал, посоветомшись, правда, с умными людЯми... я таки не буду отвечать. Дело в том, что мы с тобой будем разговаривать как китаец с французом, каждый на своем языке, и знаешь чего из этого выйдет? Прально, ничего... (кстати, общение с п.Карло в привате именно это и показало). Мы слишком разные... Я уже не помню реляционных БД, хотя когда-то в них работал, очень давно, правда... Типа в DBase, FoxBase, Access... Ты, скорее всего, никогда не работал в ООБД. Возможно, что в Оракле и т.п. M$ SQL Server-е я что-то не догоняю, хотя общался и с гуру в этих делах, и из этого общения вынес, что хранение данных в реляционных БД сводится таки к нормализации и хранению в плоских таблицах (даже в случае реализации ООП), а в Cache' ты сам определяешь стратегию хранения, как хочешь, используя многомерный сервер данных (или пользуешься стандартной, it's up to you). Твои "обычные объектные надстройки" над РСУБД притянуты туда за уши, а здесь программер работает с объектами изначально, причем из чего бы ни работал - их C++, VB, Java, Delphi, или пользуя внутренние языки - Cache' ObjectScript либо Cache'Basic...
Хранение объектов в РСУБД знаешь с чем сравнивают? Это как хранить автомобиль, разбирая его каждый раз в конце дня по запчастям, а утром собирая обратно Мягко говоря - неэффективно
Ладно, vg, я умолкаю, чтобы не продолжать разговор на разных языках...
Я ничем не хочу обидеть реляционных предшественников, более того, наверное, там, где бизнес-логика проста, пользователей немного, денег много, затраты не считают, задача не требует объектной реализации, то там имеет смысл пользоваться плоскотабличными парадигмами.
Время покажет, и все расставит на свои места...
-
- Маньяк
- Сообщения: 2758
- Зарегистрирован: 20 фев 2003, 09:15
- Откуда: Vancouver
Ну, в общем это все дело такое...
Видишь ли оченно много на свете гуру баз данных которы та ки да считают что база должна быть нормализована ваще всегда. Что естесвенно не так. Как тот мальчик с молотком. У меня напрмер база денормализована частично. Вообще нормализация изготовлена для уменьшения размера носителя данных и увеличения производительности операций изменений/добавлений. Для чиста ОЛТП систем норамлизация полезна. Склады данных простроены несколько по другому. А вот самое интересное - это когда система выполняет обе функции одновременно. Плюс некторые клиенты регулярно просят денормализовать их нюю базу бо пваять отчтеты в критсалльных отчетах им тяжело. Типа три таблицы он могут еще соединить, а больше трех - пиндец полный.george писал(а):хранение данных в реляционных БД сводится таки к нормализации и хранению в плоских таблицах Хранение объектов в РСУБД знаешь с чем сравнивают? Это как хранить автомобиль, разбирая его каждый раз в конце дня по запчастям, а утром собирая обратно Мягко говоря - неэффективно
Ладно, vg, я умолкаю, чтобы не продолжать разговор на разных
Про автомобиль пример клаасный но неправильный. Лично я буду хранить автомобиль целиком даже ежели это супротив третьей нормальной формы или какой там положено? Хотя да до хрена деятеолей коорые его таки разберут до винтика. Некторые клиенты на нас наехали пару раз и сказали что они хотят нормализованную базу. Ну ежели для нормализованная база - это конечная цель, то нет проблем. Сваяли как положено в книжке. Нам полностью пофиг за что бабки получать. Ежели завтра клиент скажет что хочет ваять на это Каше - бум ваять на Каше. Не просят. Просят Оракл, Мелкомягкий, Информикс.
-
- Маньяк
- Сообщения: 2803
- Зарегистрирован: 29 май 2003, 22:29
- Откуда: Магадан - Миссиссага
2george,
2) «Не буду отвечать…..» Дык ведь ответил же
На самом деле после нескольких месяцев общения на форуме у меня сложилось впечатление, что если не Россия, то уж её отдалённые регионы точно – отсталая, дремучая страна в IT. Мне, например, даже на уровне терминологии часто трудно разобраться, о чём речь.
Теперь немного яда:
Отсюда и мои вопросы были тебе. Всё знать невозможно. Могу сказать ещё больше о себе. Я ещё меньше, похоже, знаю здесь, чем ты. Из того набора, что ты пропостил – Оракл надо вычеркнуть для моей персоны.
2) Я действительно не знаю, как организованны данные в «настоящих» OODB. Но исходя из моих безусловно скромных познаний в IT, и из того, что чудес не бывает, возьму на себя смелость сказать, что никакого персистентного представления объектов (объектов - в поведенческом смысле) не существует вообще. В конечном случае – всё храниться «плоско». Плоская модель памяти и её обработки - у современных компьютеров. Всё адресуется в примитивном линейном адресном пространстве. И там нет места для объектов. Объектное представление в программировании это только плод фонтазии программиста. Да и то, только на стадии компиляции. В ран-тайме не существует никаких объектов. Здесь, я не хочу ни в коем случае переводить тему в другое русло, спорить о том, что один из подходов (например, «компонентное программирование») объектнее или персистентскее другого. Но думаю, что и в «настоящих» ООБД – всё храниться весьма плоско в конечном счёте. Выпуклость и впуклость существует, только тогда, когда ты при помощи неких скриптовых, визардовых средств описываешь сущности с использованием парадигм, близких тем, что приняты в ООП.
1) Во-первых откуда ты знаешь о масштабах решаемых мною задач. Может эти масштабы таковы, что как раз объектной надстройки – достаточно. Есть конкретная задача, конкретный инструмент, конкретный результат. Я и не склонен обобщать ЭТО на другие задачи. Универсальных технологий не существует вовсе. Не бывает «коробочек», которые спасут мир.
2) Сильно по своей неграмотности подозреваю, даже не зная как работает Cache, что от так и поступает -
3)
ПС. Ваще мне всё не пофиг
1) Ну, с умными, так с умными. Да, прости ты нас дураков .я знаешь чего надумал, посоветомшись, правда, с умными людЯми... я таки не буду отвечать.
2) «Не буду отвечать…..» Дык ведь ответил же
Это точно. Именно поэтому я и задаю вопросы. Если иногда в язвительной форме, - так чего обижаться-то на дурачков? А посмотри, как меня здесь «колбасят». И что из этого?Дело в том, что мы с тобой будем разговаривать как китаец с французом, каждый на своем языке, и знаешь чего из этого выйдет? Прально, ничего... (кстати, общение с п.Карло в привате именно это и показало). Мы слишком разные...
На самом деле после нескольких месяцев общения на форуме у меня сложилось впечатление, что если не Россия, то уж её отдалённые регионы точно – отсталая, дремучая страна в IT. Мне, например, даже на уровне терминологии часто трудно разобраться, о чём речь.
Теперь немного яда:
Просто совет. Не прикрывайся любым приватом. Отвечай сам за себя. Ну, и, кроме того, если уж пишешь кому либо в приват, то незачем об этом трубить на весь форум. Без обид.кстати, общение с п.Карло в привате именно это и показало
Ты прав. Я никогда не работал с «настоящими» ООДБ. Хотя, если честно – то я вообще не очень-то здесь верю в «настоящее», гуру и авторитетам (за исключением Лепсика, Папы Карлы и Мармота, естественно)Типа в DBase, FoxBase, Access... Ты, скорее всего, никогда не работал в ООБД. Возможно, что в Оракле и т.п. M$ SQL Server-е я что-то не догоняю,
Отсюда и мои вопросы были тебе. Всё знать невозможно. Могу сказать ещё больше о себе. Я ещё меньше, похоже, знаю здесь, чем ты. Из того набора, что ты пропостил – Оракл надо вычеркнуть для моей персоны.
1) То были не те гуру, или ты не то «вынес». Те определения, что выше, если уж говорить, что к чему сводится – суррогат. Очень примитивный взгляд. Имхо, конечно.хотя общался и с гуру в этих делах, и из этого общения вынес, что хранение данных в реляционных БД сводится таки к нормализации и хранению в плоских таблицах (даже в случае реализации ООП),
2) Я действительно не знаю, как организованны данные в «настоящих» OODB. Но исходя из моих безусловно скромных познаний в IT, и из того, что чудес не бывает, возьму на себя смелость сказать, что никакого персистентного представления объектов (объектов - в поведенческом смысле) не существует вообще. В конечном случае – всё храниться «плоско». Плоская модель памяти и её обработки - у современных компьютеров. Всё адресуется в примитивном линейном адресном пространстве. И там нет места для объектов. Объектное представление в программировании это только плод фонтазии программиста. Да и то, только на стадии компиляции. В ран-тайме не существует никаких объектов. Здесь, я не хочу ни в коем случае переводить тему в другое русло, спорить о том, что один из подходов (например, «компонентное программирование») объектнее или персистентскее другого. Но думаю, что и в «настоящих» ООБД – всё храниться весьма плоско в конечном счёте. Выпуклость и впуклость существует, только тогда, когда ты при помощи неких скриптовых, визардовых средств описываешь сущности с использованием парадигм, близких тем, что приняты в ООП.
Вот поэтому я и спрашивал тебя о тех абстрациях, которые доступны в Cache. И здесь ты, к сожалению, ничего не ответил. Это интересно для меня было на самом деле.а в Cache' ты сам определяешь стратегию хранения, как хочешь, используя многомерный сервер данных (или пользуешься стандартной, it's up to you).
Воспринимаю это в качестве твоих эмоций. Только три замечания.Твои "обычные объектные надстройки" над РСУБД притянуты туда за уши, а здесь программер работает с объектами изначально, причем из чего бы ни работал - их C++, VB, Java, Delphi, или пользуя внутренние языки - Cache' ObjectScript либо Cache'Basic...
1) Во-первых откуда ты знаешь о масштабах решаемых мною задач. Может эти масштабы таковы, что как раз объектной надстройки – достаточно. Есть конкретная задача, конкретный инструмент, конкретный результат. Я и не склонен обобщать ЭТО на другие задачи. Универсальных технологий не существует вовсе. Не бывает «коробочек», которые спасут мир.
2) Сильно по своей неграмотности подозреваю, даже не зная как работает Cache, что от так и поступает -
Если это не так, то возможно, что это весьма неэффективное «избыточное» объектное представление, принятое, например, в Geodatabase ArcGis (продукт компании ESRI).«…в конце дня по запчастям, а утром собирая обратно…»
3)
этим я баловался давно, когда писал диссертацию. Уже давно переболел и выздоровел. Когда работаешь на производстве, то с тебя спрашивают результат.«…притянуты туда за уши…»
Очень жаль, поскольку беседа могла быть продуктивной. Для меня.Ладно, vg, я умолкаю, чтобы не продолжать разговор на разных языках...
Не будь ребёнком. Обидеть – не обидеть. Прям красна девица.Я ничем не хочу обидеть реляционных предшественников, более того, наверное, там, где бизнес-логика проста, пользователей немного, денег много, затраты не считают, задача не требует объектной реализации, то там имеет смысл пользоваться плоскотабличными парадигмами.
Время покажет, и все расставит на свои места...
ПС. Ваще мне всё не пофиг
-
- Маньяк
- Сообщения: 2803
- Зарегистрирован: 29 май 2003, 22:29
- Откуда: Магадан - Миссиссага
2Володя,
Нормализация выполняет в общем случае (на уровне логики клиентского приложения, хотя и определяется на уровне представления данных на сервере) ещё одну очень важную роль. Помимо объектов защиты целостности ссылок (что безусловно присутствует) нормализация часто позволяем уменьшить вероятность нарушения непротиворечивости данных.
Просто эти люди занимаются задачками, кроме которых ничего больше не видели.Видишь ли оченно много на свете гуру баз данных которы та ки да считают что база должна быть нормализована ваще всегда.
Часто это правильно, если мы за чистоту результата, а не идей и постулатов.У меня напрмер база денормализована частично.
Вообще нормализация изготовлена для уменьшения размера носителя данных и увеличения производительности операций изменений/добавлений.
Нормализация выполняет в общем случае (на уровне логики клиентского приложения, хотя и определяется на уровне представления данных на сервере) ещё одну очень важную роль. Помимо объектов защиты целостности ссылок (что безусловно присутствует) нормализация часто позволяем уменьшить вероятность нарушения непротиворечивости данных.
Такой подход никто в практике не использует. Приведите примеры.Хотя да до хрена деятеолей коорые его таки разберут до винтика.