Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 [15] 16 17 18 19 .. 27   вперед  Ctrl
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Бред

Опять ошибаетесь из-за невнимательности): Надеюсь):
Никакая это не классическая задача): "Классическая "задача" это только
Изделие <-Состоит из/Входит в-> Изделие

Чтобы Вы (вместе с _мод) поняли продолжу список:
Изделие <-Состоит из/Входит в-> Изделие
Изделие <-Используется как комплектующее для/Является комплектующим для-> Изделие
Изделие <-Используется для упаковки/Упаковывается в-> Изделие
Изделие <-Использует в качестве аналога/Является аналогом- Изделие

С точки зрения модели данных пока я не вижу сколько-нибудь существенной разницы с bill of materials.

Бред

И т.д.
Ну а дальше у Вас опять голые декларации про "грамотно построенную архитектуру", которая:
1) является вынужденным решением из-за недостатков РМД;

А почему на нереляционном IMS и коболе тоже таким (многоуровневым а не монолитным) макаром системы строят? CICS например за каким ... используют? Хотите я вам сейчас нереляционных примеров многоуровневой архитектуры накидаю вагон и маленькую тележку? Из монолитов навскидку на ум приходит только z/TPF но это кадавр написанный на мэйнфреймовом ассемблере лет 40 тому назад. Все остальные мало-мальски масштабируемые системы обработки транзакций как реляционные так и не реляционные построены по принципам многоуровневой архитектуры. Если хотите понять почему - загляните в классическую книжку Джима Грея по обработке транзакций. Кстати, "внутрях" реляционной СУБД тоже уровни с интерфейсами, и нижний уровень в некоторых из них это нечто мампсоидное, как в Каше. Этакий базоданновый ассемблер.

Бред

2) удлиняет сроки разработки и снижает качество приложений;

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


Бред

3) приводит к постоянному программированию даже самых простых приложений.

Сразу видно что с вышеуказанными продуктами для Business Intelligence вы никогда не работали. Архитектор организовывает в репозиторий метаданных, после чего юзера сами тянут из базы нужные себе отчеты. Я такое собственноручно делал на Microstrategy так что за работоспособность этого подхода отвечаю. На Business Objects тоже народ делает очень пристойные системы. Сам я из с нуля не делал, но руками трогал. Даже на убогом оракловом Discoverer можно такие штуки делать.


Бред

И, конечно, у этих безобразных, а не "грамотных" архитектур есть лидеры, кто бы сомневался):
Но это теория, а почему бы Вам не показать на рассматриваемых конкретных примерах, как все делается в "грамотных архитектурах"?): Вот _мод хотя бы старается показать. Может Вы ему поможете?):

За 150 долларов в час я вам сделаю полностью работоспособное решение. А на примерах что я вам буду показывать? Скриншоты интерфейса Microstrategy? Объяснять как оно работает и учить? За один класс Microstrategy дерет 3 штуки баксов. Набирайте группу из 5-10 человек и гоните 2 с половиной штуки с носа, билет из Сан Франциско в Москву и обратно и гостиницу. Я объясню, научу, покажу и расскажу. Иначе мне нет смысла ломаться. "Нас и здесь неплохо кормят" (С).
12 июл 08, 07:53    [5925274]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
MX -- ALEX
Guest
реляционный дебил

Но ведь нам не придет в голову представить эту иерархию в обратном виде, когда министр управляет Путиным. Значит, все-таки тут не полный произвол, а в природе все-таки что-то есть, что заставляет нас сильно ограничивать наш выбор иерархии. Вот я и хочу понять, что это за критерии.

Придет - в революцию
В мирное время инстинкт самосохранения заставляет людей поддерживать
управление обществом сверху вниз иначе анархия и кровь

реляционный дебил

MX -- ALEX
Компьютеру иерархия (например : файлов-папок) не нужна -
она нужна человеку
чтоб не рехнуться окончательно

Ну почему же. Документы хранятся в папках, а папки на полки, а полки в шкафах, а шкафы в комнатах, а комнаты в зданиях, а здания в государстве и т.д. Мы же не можем эту иерархию изменить произвольным образом, поскольку она такая в природе. Ведь мы не говорим, что шкаф находится в документе.

бумажные папки и шкапы придумал человек из за ограниченности моска
это не совсем дикая природа

реляционный дебил

MX -- ALEX
принцип построения иерархий - чисто субьективный - как нам удобнее
натаскивать "это" на базу данных - необязательно

С этим я соглашусь, но произвол в построении иерархии примерно такой же как в выборе структуры отношений. Но с отношениями как-то понятно, поскольку мы говорим, что одна сущность в природе соответствует одному отношению (произвол только в выборе сущностей и их параметров). А в случае иерархии мы говорим о связях, поэтому вопрос в том, какие связи являются иерархическими, а какие просто так. Например, можно предполжить, что связь один-ко-многим это иерархия (один родитель - много детей).

а природе безразлично кто тут родители кто дети и кто сущность,
где причина и где следствие -
гоняет себе волны туда сюда и возникает из них всякая хрень
типа люди - компы - черные дыры и т п
волны эти потихоньку затухают поэтому
диаметры атомов сокращаются, метр в Лувре укорачивается,
расстояния между галактиками в этих "метрах"
увеличиваются (кажется что галактики разбегаются )

это я к тому что спорить о преимуществах разных схем представления данных бесполезно
как нам ( субьективно ) удобнее так и будем представлять

Вообще тут бы надо психотерапевта и ящик вотки
12 июл 08, 23:54    [5926223]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Зл0й
Бред

Опять ошибаетесь из-за невнимательности): Надеюсь):
Никакая это не классическая задача): "Классическая "задача" это только
Изделие <-Состоит из/Входит в-> Изделие

Чтобы Вы (вместе с _мод) поняли продолжу список:
Изделие <-Состоит из/Входит в-> Изделие
Изделие <-Используется как комплектующее для/Является комплектующим для-> Изделие
Изделие <-Используется для упаковки/Упаковывается в-> Изделие
Изделие <-Использует в качестве аналога/Является аналогом- Изделие

С точки зрения модели данных пока я не вижу сколько-нибудь существенной разницы с bill of materials.

Бред

И т.д.
Ну а дальше у Вас опять голые декларации про "грамотно построенную архитектуру", которая:
1) является вынужденным решением из-за недостатков РМД;

А почему на нереляционном IMS и коболе тоже таким (многоуровневым а не монолитным) макаром системы строят? CICS например за каким ... используют? Хотите я вам сейчас нереляционных примеров многоуровневой архитектуры накидаю вагон и маленькую тележку? Из монолитов навскидку на ум приходит только z/TPF но это кадавр написанный на мэйнфреймовом ассемблере лет 40 тому назад. Все остальные мало-мальски масштабируемые системы обработки транзакций как реляционные так и не реляционные построены по принципам многоуровневой архитектуры. Если хотите понять почему - загляните в классическую книжку Джима Грея по обработке транзакций. Кстати, "внутрях" реляционной СУБД тоже уровни с интерфейсами, и нижний уровень в некоторых из них это нечто мампсоидное, как в Каше. Этакий базоданновый ассемблер.

Бред

2) удлиняет сроки разработки и снижает качество приложений;

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


Бред

3) приводит к постоянному программированию даже самых простых приложений.

Сразу видно что с вышеуказанными продуктами для Business Intelligence вы никогда не работали. Архитектор организовывает в репозиторий метаданных, после чего юзера сами тянут из базы нужные себе отчеты. Я такое собственноручно делал на Microstrategy так что за работоспособность этого подхода отвечаю. На Business Objects тоже народ делает очень пристойные системы. Сам я из с нуля не делал, но руками трогал. Даже на убогом оракловом Discoverer можно такие штуки делать.


Бред

И, конечно, у этих безобразных, а не "грамотных" архитектур есть лидеры, кто бы сомневался):
Но это теория, а почему бы Вам не показать на рассматриваемых конкретных примерах, как все делается в "грамотных архитектурах"?): Вот _мод хотя бы старается показать. Может Вы ему поможете?):

За 150 долларов в час я вам сделаю полностью работоспособное решение. А на примерах что я вам буду показывать? Скриншоты интерфейса Microstrategy? Объяснять как оно работает и учить? За один класс Microstrategy дерет 3 штуки баксов. Набирайте группу из 5-10 человек и гоните 2 с половиной штуки с носа, билет из Сан Франциско в Москву и обратно и гостиницу. Я объясню, научу, покажу и расскажу. Иначе мне нет смысла ломаться. "Нас и здесь неплохо кормят" (С).

Ну вот видите, опять одни декларации, и намек, что говорить по существу обсуждаемых вопросов Вы согласны только за деньги): Красиво!
Итак:
1. "Тянут нужные себе отчеты" - это Вы о чем??? "Архитектор организавывает" - а это о чем???
То, о чем Вы говорите просто убожество):
2. И я с ним знаком не хуже Вас, так что опять ошибаетесь):
3. Я Вам готов рассказать про БД бесплатно, и если у Вас нет средств к существованию, могу оплатить проживание в Москве):
14 июл 08, 01:35    [5927525]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Бред

Ну вот видите, опять одни декларации, и намек, что говорить по существу обсуждаемых вопросов Вы согласны только за деньги): Красиво!
Итак:
1. "Тянут нужные себе отчеты" - это Вы о чем??? "Архитектор организавывает" - а это о чем???

Если говорить предметно, то я лично, выступая в роли BI Architect залезаю в Metadata Repository через Microstrategy Desktop и задаю там такие вещи как measures, hierarchies, drill maps и далее по списку. Некоторое отчетов Microstrategy Desktop я клепаю сам, в качестве образца. После этого предварительно обученный мной или моими сотрудниками пользователь (например сотрудница бухгалтерии, сотрудник маркетингового отдела) через Excel-подобный web-интерфейс используя созданные мной отчеты в качестве образца создает свои собственные отчеты. Мышью практически без программирования. При этом не пишет не одной строчки SQL. Его генерирует Microstrategy.


Бред

То, о чем Вы говорите просто убожество):
2. И я с ним знаком не хуже Вас, так что опять ошибаетесь):

Вы работали конкретно с Microstrategy или Business Objects? Судя потому что говорите "убожество" вы в глаза их не видели. Если я ошибаюсь, то конкретые претензии - в студию. Я всяких "претензий" наслушался, в 99% случаев у них ноги растут из неумения пользоваться продуктом и непонимания что такое Хранилище данных и с чем его едят.

Бред

3. Я Вам готов рассказать про БД бесплатно, и если у Вас нет средств к существованию, могу оплатить проживание в Москве):

Я застал времена когда СССР был еще жив и здоров. Времена "развитого социализма" прошли, и я бесплатно не работаю, ни при каких обстоятелствах. С одной стороны работа должна адекватно оплачиваться с другой стороны она должна качественно выполняться. Во всех остальных случаях я не участвую, потому что мне как профессионалу это не интересно. Я со своих клиентов беру 150 долларов в час, при этом часть работы приходится отдавать друзьям-конкурентам потому что у меня физически нет возможности выполнить все заказы. В сутках 24 часа, работать на протяжении длительного времени более чем по 12 часов в сутки я уже не могу, возраст не тот.
14 июл 08, 08:14    [5927672]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
реляционный дебил
Например, можно взять те же номера строк в любой РСУБД ну или те же PK-FK и адаптировать их для сетевой модели. Почему тогда так до сих пор не сделали, ведь это просто?

Это не очень просто - пример rowid в Oracle не гарантирован от изменений и его нельзя использовать для ссылок. Вообщем, ныненшие технологии просто не доросли до сетевой модели.
14 июл 08, 10:45    [5928251]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Ну хорошо, я попытаюсь, а Вы поправьте, пожалуйста.

Поправим. Варианты:
РСУБД: два столбца: ссылка на родителя, ссылка на себя
ССУБД: таблица без столбцов (!) + связь с таблицей родителей + связь с основной таблицей
все это описывается на сотв. DDL
14 июл 08, 10:49    [5928292]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред

Вы все сильно усложняете. Просто есть два эквивалентных варианта реализации множественных связей 1) именовать связи 2) вводить синонимы. В случае 2 связи не именуются и поэтому синтаксис DML становится проще. В разных СУБД применяются оба подхода.
14 июл 08, 10:56    [5928360]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
В "моей" модели

Вот с этого и надо было начинать. Оказывается у вас есть модель ! А где ее описание и желательно в мат. терминах - множества, функции и т.д. ?
14 июл 08, 11:00    [5928406]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Зл0й
Бред

Ну вот видите, опять одни декларации, и намек, что говорить по существу обсуждаемых вопросов Вы согласны только за деньги): Красиво!
Итак:
1. "Тянут нужные себе отчеты" - это Вы о чем??? "Архитектор организавывает" - а это о чем???

Если говорить предметно, то я лично, выступая в роли BI Architect залезаю в Metadata Repository через Microstrategy Desktop и задаю там такие вещи как measures, hierarchies, drill maps и далее по списку. Некоторое отчетов Microstrategy Desktop я клепаю сам, в качестве образца. После этого предварительно обученный мной или моими сотрудниками пользователь (например сотрудница бухгалтерии, сотрудник маркетингового отдела) через Excel-подобный web-интерфейс используя созданные мной отчеты в качестве образца создает свои собственные отчеты. Мышью практически без программирования. При этом не пишет не одной строчки SQL. Его генерирует Microstrategy.


Бред

То, о чем Вы говорите просто убожество):
2. И я с ним знаком не хуже Вас, так что опять ошибаетесь):

Вы работали конкретно с Microstrategy или Business Objects? Судя потому что говорите "убожество" вы в глаза их не видели. Если я ошибаюсь, то конкретые претензии - в студию. Я всяких "претензий" наслушался, в 99% случаев у них ноги растут из неумения пользоваться продуктом и непонимания что такое Хранилище данных и с чем его едят.

Бред

3. Я Вам готов рассказать про БД бесплатно, и если у Вас нет средств к существованию, могу оплатить проживание в Москве):

Я застал времена когда СССР был еще жив и здоров. Времена "развитого социализма" прошли, и я бесплатно не работаю, ни при каких обстоятелствах. С одной стороны работа должна адекватно оплачиваться с другой стороны она должна качественно выполняться. Во всех остальных случаях я не участвую, потому что мне как профессионалу это не интересно. Я со своих клиентов беру 150 долларов в час, при этом часть работы приходится отдавать друзьям-конкурентам потому что у меня физически нет возможности выполнить все заказы. В сутках 24 часа, работать на протяжении длительного времени более чем по 12 часов в сутки я уже не могу, возраст не тот.

0. Вы ловко перескочили с БД на ХД, но это Вам не поможет):
1. В БД неизвестен смысл данных
Сидоров, 45, 01.05.2003
?
Ну предположим, что "первый архитектор" подкачал, и смысл не известен.
"Второй архитектор" подумал и решил, что 45 - это вес Сидорова в кг, измеренный 01.05.2003.
Сделал отчеты, и ничего не подозревающие "пользователи" начали их тащить):
Однако "третий архитектор" подумал и решил, что 45 - это общее количество суток, которое Сидоров отсидел в КПЗ, а 01.05.2003 - дата окончания последней отсидки. Сделал отчеты, и пользователи начали их тащить, и уже просто тащиться от этих "архитекторов", и жизнь для них буквально заиграла новыми красками):
Или "первый архитектор" не подкачал, и в БД уже есть смысл в данных, а "второй архитектор" (с помощниками!) просто повторно воспроизводит этот смысл в другой системе. А "пользователям" объясняет, что "это все придумал Черчиль в 18-м году" (или Кодд в 1969 - суть не меняется), и будьте добры оплатить за "специализированную систему представления смысла данных"):
Никогда не сомневался, что нужно быть весьма умным человеком, чтобы обманывать других людей, но должен напомнить, что автор РМД как раз надеялся, что пользователи сами смогут работать с данными в БД):
2. Сказки про хранилища данных мне не нужно рассказывать. Я за свои слова отвечаю. Именно убожество. Не код, конечно, а концепция, и я много раз объяснял почему): И сейчас еще раз объяснил.
3. Какая еще работа. Вы совершенно запутались, и я икренне хочу Вам помочь. Если денег совсем нет могу и питание оплатить): А Вы о какой-то своей работе): Видимо об этой:
Сначала сами себе придумали "монолит"???
Тут же приписали эту "идею" мне!??
И начали ее "опровергать" путем рассказа об удивительной архитектуре со специализированными системами представления смысла данных, потому что метаданные СУБД не в состоянии представить смысл данных, хотя он где-то там, все-таки, есть (или "первый архитектор", все-таки, подкачал???).
Вот я Вам и говорю: пожалуйста, на конкретном примере. Вам нужен час, а это стоит 150 долларов? Ну хорошо, сообщите как я Вам могу заплатить 150 долларов (мне проще всего передать наличными кому-нибудь в Москве):).
15 июл 08, 00:02    [5933239]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Ну хорошо, я попытаюсь, а Вы поправьте, пожалуйста.

Поправим. Варианты:
РСУБД: два столбца: ссылка на родителя, ссылка на себя
ССУБД: таблица без столбцов (!) + связь с таблицей родителей + связь с основной таблицей
все это описывается на сотв. DDL

Здесь Вы видимо подразумеваете какой-то конкретный пример? "Родители", "на себя", "основная таблица"??? Что же Вы "поправили"? Только запутали): Таблицы не нужны для представления связей - так Вы говорили раньше. А теперь таблица, оказывается, нужна. Но без столбцов. А зачем она нужна? Чья "связь с таблицей родителей"??? Чья "связь с основной таблицей"???
Можете, наконец-то, объяснить на конкретном примере, или Вам тоже нужно заплатить 150 долларов?
15 июл 08, 00:17    [5933266]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред

Вы все сильно усложняете. Просто есть два эквивалентных варианта реализации множественных связей 1) именовать связи 2) вводить синонимы. В случае 2 связи не именуются и поэтому синтаксис DML становится проще. В разных СУБД применяются оба подхода.

Простите, что я "сильно усложнил" в этом простом тексте:
-----
Ну хорошо, не хотите рассматривать мой пример, давайте рассматривать Ваш, в котором есть "таблица" "Состав изделия", по всей вероятности, с одной колонкой "Количество" (изделия, входящего в изделие), так как "ссылок" (то есть связей с "таблицей" "Изделие"), как мы помним, не должно быть в колонках этой таблицы. Правильно?
Итак, у нас два объекта и две связи между ними:
Изделие <-Используется как составное/Для- Состав изделия
Изделие <-Используется как компонента/Имеет в качестве компоненты- Состав изделия
В "моей" модели (то есть в классической объектной модели) в метаданных действительно хранится два объекта и две связи между ними. Вы же после некого преобразования (а зачем Вы делали какое-то странное "преобразование", и в чем заключается алгоритм преобразования "многоштриховых стрелочек"?) получили три объекта - так это выглядит на схеме БД после "преобразования". Или это некое "представление", а в схеме БД по-прежнему два объекта? Или, как Вы любите повторять, в "вычислительной модели" два объекта и две связи (но как они там представлены-то объясните, в конце концов):), а в какой-то "невычислительной модели" три объекта и две связи:

Изделие составное <-(семантика связи не нужна, так как помещена разработчиком в название фиктивного объекта)- Состав изделия
Изделие-компонента <- Состав изделия

Но ведь один и тот же экземпляр изделия (из "вычислительной модели") может присутствовать и в "таблице" "Изделие составное", и в "таблице" "Изделие-компонента" "невычислительной модели". Следовательно, очевидно, что в этих таблицах ничего не хранится. А все хранится в двух таблицах "вычислительной модели". Правильно? Так где же здесь "упрощение", и в чем оно заключается??? И еще раз спрашиваю: как в метаданных хранится "вычислительная модель" и как в ней отражены две связи между двумя объектами? Что представляет собой "невычислительная модель"? Представление для приложения, или что?
-----
что Вы опять ушли от оветов на конкретные вопросы?????
Скажите, я постараюсь переформулировать):
15 июл 08, 00:22    [5933274]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
В "моей" модели

Вот с этого и надо было начинать. Оказывается у вас есть модель ! А где ее описание и желательно в мат. терминах - множества, функции и т.д. ?
ешите
Ой, не смешите): И объектная не моя (поэтому я пишу "моя"), и сетевая не Ваша, поэтому я пишу "Ваша". Использую кавычки. Пожалуйста, не уходите от сути вопросов, и не выбирайте слова из текстов, чтобы уйти от сути):
15 июл 08, 00:26    [5933278]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Бред

0. Вы ловко перескочили с БД на ХД, но это Вам не поможет):

Речь шла о построении системы отчетов. Вот я и использую стандартный BI инструмент. Если мне надо небольшой текстовый файл отсортировать я тоже использую стандартный юниксовый sort, а не пишу свою программулину на сях. Время-деньги. Да и изобретать велосипед в 2001й раз мне неинтересно.

Бред

1. В БД неизвестен смысл данных
Сидоров, 45, 01.05.2003
?

А метаданные про которые я вам уже который раз пишу на что? Ваша изначальная послылка неверна, т.к. в БД Microstrategy хранит репозиторий метаданных:

таблица="people", колонка="last_name", описание="Фамилия",
таблица="people", колонка="weight_kg", описание="вес в кг",
таблица="people", колонка="incarceration_date", описание="дата отсидки"


Бред

будьте добры оплатить за "специализированную систему представления смысла данных"):

Есть бесплатные, причем с открытым кодом. Pentaho например.

Бред

2. Сказки про хранилища данных мне не нужно рассказывать. Я за свои слова отвечаю. Именно убожество. Не код, конечно, а концепция, и я много раз объяснял почему): И сейчас еще раз объяснил.

Вы конкретно с Microstrategy и Business Objects не работали, судя по тому что пишете. Убожество, говорите, "А пацаны-то не знают" (С). У пацанов из таких компаний как Google, Ebay, Wells Fargo Bank почему-то это "убожество" нормально работает. Народ не жалуется.

Бред

3. Какая еще работа. Вы совершенно запутались, и я икренне хочу Вам помочь.

Мне как раз все ясно, могу либо сделать, либо научить как делать. Но за деньги.


Бред

Если денег совсем нет могу и питание оплатить): А Вы о какой-то своей работе): Видимо об этой:
Сначала сами себе придумали "монолит"???
Тут же приписали эту "идею" мне!??

Объектный навигатор - надстройка над кашей. Интерфейс позволяющий заменить кашу на что-то другое - где? Вот я например могу из Microstrategy гонять одни и те же отчеты которые вынимают данные из Оракла и Teradata. Если на балабановской фабрике заменить кашу на GT.M что будет?

Бред

И начали ее "опровергать" путем рассказа об удивительной архитектуре со специализированными системами представления смысла данных, потому что метаданные СУБД не в состоянии представить смысл данных, хотя он где-то там, все-таки, есть (или "первый архитектор", все-таки, подкачал???).

Берете Microstrategy Desktop лезете в репозиторий метаданных и будет вам счастье.

Бред

Вот я Вам и говорю: пожалуйста, на конкретном примере. Вам нужен час, а это стоит 150 долларов? Ну хорошо, сообщите как я Вам могу заплатить 150 долларов (мне проще всего передать наличными кому-нибудь в Москве):).

Хватит ваньку валять. У вас есть конкретный проект где нужны мои услуги? Я меньше чем на 6 месяцев на консалтинг обычно не подписываюсь. Если речь о том что я должен куда-то ехать то минимум 12 месяцев, и я еще крепко подумаю ехать мне или нет.
15 июл 08, 00:36    [5933291]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Здесь Вы видимо подразумеваете какой-то конкретный пример?

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

Для представления сущности Состав изделия=Ребра графа. Чего не понятного-то ? Если ребра не нагружены, то и столбцов нет.
15 июл 08, 09:39    [5933826]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Ой, не смешите): И объектная не моя (поэтому я пишу "моя")

Давайте описание "вашей " "объектной" (тогда и посмеемся)
15 июл 08, 09:41    [5933840]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред

1. В БД неизвестен смысл данных
Сидоров, 45, 01.05.2003
?

Ну вы открыли америку ! Ессно не известен, и не д.б. известен. Это же МД, котрая м.б. проинтепретирована только ее автором. Это основной принцип моделирования данных, странно (и очень сильно подозрительно) что вы этого не понимаете.
15 июл 08, 09:45    [5933869]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Бред
_мод
Бред
Ну хорошо, я попытаюсь, а Вы поправьте, пожалуйста.

Поправим. Варианты:
РСУБД: два столбца: ссылка на родителя, ссылка на себя
ССУБД: таблица без столбцов (!) + связь с таблицей родителей + связь с основной таблицей
все это описывается на сотв. DDL

Здесь Вы видимо подразумеваете какой-то конкретный пример? "Родители", "на себя", "основная таблица"??? Что же Вы "поправили"? Только запутали): Таблицы не нужны для представления связей - так Вы говорили раньше. А теперь таблица, оказывается, нужна. Но без столбцов. А зачем она нужна? Чья "связь с таблицей родителей"??? Чья "связь с основной таблицей"???
Можете, наконец-то, объяснить на конкретном примере, или Вам тоже нужно заплатить 150 долларов?


Ответьте пожалуйста мне на вопрос являются ли связи(их свойства, параметры) данными, если не являются то чем они есть на самом деле с точки зрения модели.

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

з.ы. Я очень прошу вас не касаться темы физического хранения, вопрос не в хранении,
вопрос именно в модели данных.
15 июл 08, 11:28    [5934741]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
onstat-
Ответьте пожалуйста мне на вопрос являются ли связи(их свойства, параметры) данными, если не являются то чем они есть на самом деле с точки зрения модели.

И да и нет. Если две таблицы t1 и t2 связаны 1:N, то это означает что каждая строка t2 содержит скрытый столбец, содержащий номер строки t1. Этот столбец не доступен для изменения, но м.б. доступен для чтения - псевдостолбец - это полезно. В DDL псевдостолбцы не описываются а описывается именно связь между t1 и t2. Это сетевая МД.
15 июл 08, 11:44    [5934938]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
_мод
onstat-
Ответьте пожалуйста мне на вопрос являются ли связи(их свойства, параметры) данными, если не являются то чем они есть на самом деле с точки зрения модели.

И да и нет. Если две таблицы t1 и t2 связаны 1:N, то это означает что каждая строка t2 содержит скрытый столбец, содержащий номер строки t1. Этот столбец не доступен для изменения, но м.б. доступен для чтения - псевдостолбец - это полезно. В DDL псевдостолбцы не описываются а описывается именно связь между t1 и t2. Это сетевая МД.


Из вашего ответа данными они не являются потому как скрытый столбец( ссылка)
есть только метаинформация.

Как быть со свойствами? Как связи привязать определенные свойства?

Свойства связей не тоже самое что свойства обьектов.
С точки зрения модели это важно, иначе никаких преймуществ относительно РМД я не вижу.

В РМД можно описать таблицу связей со всеми необходимыми атрибутами как в примере про граф.
Вершины-данные, ребра-связи.
15 июл 08, 11:59    [5935078]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
onstat-
Как быть со свойствами? Как связи привязать определенные свойства?

Никак
onstat-

С точки зрения модели это важно, иначе никаких преймуществ относительно РМД я не вижу.

Особых преймуществ и нет. Просто если ID строк и PK-FK автоматически поддерживаются где-то внутри СУБД ее собственными средствами, то это м.б. полезным с разных точек зрения.
15 июл 08, 12:44    [5935524]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
_мод

Особых преймуществ и нет. Просто если ID строк и PK-FK автоматически поддерживаются где-то внутри СУБД ее собственными средствами, то это м.б. полезным с разных точек зрения.


Так очем тогда 15 страниц спорим?
Насколько я знаю РСУБД дают возмоножсть оперировать ROWID на чтение
и имеют возможность конечному пользователю осуществлять поиск по ROWID.

То есть любая РСУБД обладающая этим функционалом может считаться сетевой?
15 июл 08, 13:12    [5935791]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
onstat-
То есть любая РСУБД обладающая этим функционалом может считаться сетевой?

Не совсем. ROWID может изменяться, чего никогда не бывает в ССУБД. Но даже если бы им можно было пользоваться нужно что бы ссылки поддерживались самой СУБД, а не программистом.
15 июл 08, 13:52    [5936172]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
_мод
onstat-
То есть любая РСУБД обладающая этим функционалом может считаться сетевой?


Не совсем. ROWID может изменяться, чего никогда не бывает в ССУБД.


Я не вижу никакой разницы между сурагатным PK-FK и такой ссылкой.
Ни мататематически, ни логически, ни с точки зрения алгоритмики( программной реализации).
Хотя по последнему пункту может быть 2 варианта,
Один с совомещенным хранением ключа и rowid всех таблиц в одной структуре данных
другой классический индекс из РСУБД, первый вариант более производительный, но
имеет проблемы с масштабируемостью( добавлением новых таблиц с FК на существующий PK)
и блокировками во время выполнения, при добавлении записей в одну из FK таблиц полностью
блокирутеся работа со значением этого ключа в общей ссылке для других таблиц.

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


_мод

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



Нарисовать автоматическую поддержку ссылки через ROWID можно в любой РСУБД,
которая поддерживает пользовательские типы и их обработку.
Этим просто нужно заняться, но времени и желания хватает только на холи ва.

ps Лично мне эта сетевая модель ни капли не интересна, я пытаюсь понять что другие
в ней нашли, может я чего то еще не распробовал.
15 июл 08, 15:11    [5936752]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
студент-двоечник
Guest
onstat-
Как быть со свойствами? Как связи привязать определенные свойства?

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

onstat-
То есть любая РСУБД обладающая этим функционалом может считаться сетевой?

Нет, не может считаться. В РСУБД нет понятия связи. То, что у Вас в голове оно есть не значит, что СУБД думает так же.

onstat-
Вобщем с точки зрения модели это теже яйца, только зовутся по другому.

Как раз с точки зрения модели все по-разному. А вот реализации могут быть похожи.

onstat-
Нарисовать автоматическую поддержку ссылки через ROWID можно в любой РСУБД,
которая поддерживает пользовательские типы и их обработку.
Этим просто нужно заняться, но времени и желания хватает только на холи ва.

Ну нарисовать конечно можно, но это и будет совсем другая модель данных. Заняться тоже можно, только вот народ уже десятки лет пытается и в основном без успеха. Где-то чего-то не срастаеца.
15 июл 08, 16:15    [5937186]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
студент-двоечник
onstat-
Как быть со свойствами? Как связи привязать определенные свойства?

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



Понятие ссылочный констреинт ничем не перегружено.
Что меня сильно радует.

Как у модели с нормализацией отношений сущьностей, какие механизмы ее достижения?


Если суть термина нормализация вы не понимаете тогда есть более общий вопрос:

Каким образом модель осуществляет контроль целостности данных?
Приведите механизмы и терминологию?


автор

Так раз с точки зрения модели все по-разному. А вот реализации могут быть похожи.


Я не вижу преймуществ модели.


автор


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


Какая другая?
Делали самолет получили паравоз.

автор

Заняться тоже можно, только вот народ уже десятки лет пытается и в основном без успеха. Где-то чего-то не срастаеца.


Кто за это платит?
Зачем это нужно, лично Вам?

Так можно и комплексы заиметь, десятками лет биться над проблемой и ни с места не сдвинуться,
Может какието локальные достижения есть? В чем они заключаются?

Вся сетевая модель изложенная на этих 15 страницах ее адептами
укладывается в знания получаемые на испытательном сроке (стажировке)
толковым студентом в нормальной софтверной конторе за 2-3 месяца.
15 июл 08, 16:42    [5937349]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 [15] 16 17 18 19 .. 27   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить