Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 [12] 13 14 15 16 .. 24   вперед  Ctrl
 Re: СУБД CACHE'  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
автор
вы сами то к докторам ходили ?


У меня самого пару раз сам такие обострения случались ..... Теперича пытаюсь наблюдать со стороны...хотя, порой, язык чешется....но идь это ж надо работу бросать и писать этакие министатьи....
18 ноя 04, 16:50    [1117790]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
dimon_n2000
причем логические деревья храняться в Б деревьях, ибо это самый оптимальный способ физического хранения данных в борьбе за производительность и компактность.
...
РСУБД вынуждены хранить данные несколькими способами, поскольку изначально реляц модель предполагает отсутствие ключа, а следовательно отсутсвие идентификации записи. а раз нет идентфикации, то и обращаться можно токо к куче. чего и наблюдаем в оракл, например. как токо идентфикация пояляется (индексы например), то и хранить тут же предлагается в Б дереве, ибо оно оптимально.


Т.е. получается что иерархическая модель подобна ораклу если б там был возможен только один индекс на таблицу?
18 ноя 04, 16:52    [1117809]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
dimon_n2000

каше есть в фундаменте - М. Это иерархическая модель.

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

dimon_n2000

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

Вот это пока сбивает с толку. Не ложится в привычную схему. Получается три уровня? ООМД или РМД - один логический уровень, Иерархическая МД - второй логический уровень и третий - еще физический уровень?

dimon_n2000

насчет более оптимального способа хранения

Например, В РМД известно, что если поля содержат почти одинаковые значения, то Б - дерево не очень хорошо подходит для индекса, Битмап индесы - хорошо.
18 ноя 04, 16:52    [1117813]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 dimon_n2000

Ну вот всё так хорошо начиналось ....

>>да, сложновато объяснять в письменном виде. вы вообще про что то другое говорите.....

Если в писменном сложновато, то устно даже и не пробуйте - фигня получится.

>>во первых я не шучу. про реализхованный во всех М системах физический способ хранения в виде Б дерева я знаю все.

Рад за вас. Искренне рад.


>>Это не М системы, разумеется придумали. Они его все используют.

Его не только М используют. Его все используют. Кроме дятлов, наверное, им не до теории, им надо : долбить, долбить, долбить :))

>>И там нет никаких сложностей, о которых вы пытались чего то написать.

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

>>Производительность - железно логарифм и в никакой список он не выраждается.

Вырождается, молодой человек, вырождается. Не надо было прогуливать лабораторки где приводились реализации Б-деревьев, хотя если вы инженер-механик может у вас их и не было, попробуйте сами реализовать Б-дерево и операции над ним (delete и insert). Увидите где там происходит вырождение :)

>>скорость доступа - количство уровней блоков указателей. в каше, например, при размере логического дерва в миллион записей нужно с диска поднимать всегда три блока не зависимо от того, сколько само дерево будет занимать.

Безусловно это так. А вы этот миллион как записали так больше никогда не будете изменять ?


>>тут вам надо почитать Паскаля, который алгоритм Б дерева описывает.

Ну вот :) ПОЧИТАЛ :) Я не очень хорошо представляю себе что такое "алгоритм Б-дерева". Про структуру под названием Б-дерево знаю, про операции над ними знаю.

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

А я считаю. Хотя бы потому, что провожу в форуме бесплатный ликбез а мне в ответ вместо спасибо - "... вам надо почитать Паскаля который алгоритм Б-дерева (!) описывает ... ".

>>других людей я так же глупыми не считаю.

Это вас украшает и выгодно отличает от коллеги ЧАЛ-а, например.

>>у каждого - свой мир. и мировосприятие разное.

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


>>если у вас нет уважения к самому себе - вы можете себя называть глупым или глупее чем дядьки в айбим.

Боюсь там больше одного дядьки и даже больше двух :)

>>меня туда не причисляйте, пжлста.

Да пожалуйста : "Весь штат сотрудников IBM и ORACLE вместе взятых не умнее чем dimon_n2000 с форума на SQL.RU"


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


Живой пример :

Хранение объекта типа накладная (у него как минимум есть дата,артикул,количество,цена). Если хранить его в дереве, что выбрать в какчестве идентифицирующего атрибута ? Или добавить суррогат (хорошо-хорошо OID) ? Если выбираем в качестве идентификатора артикул - выборка всех накладных за интервал дат представляет из себя обход всего дерева кроме того у артикула может быть невысокая кардинальность (об этом вам говорил vadiminfo) тогда ваше дерево превратиться в несколько связных списков. Если дату - тогда выбор всех документов для данного артикула приведёт к полному обходу дерева. И т.п. Если заведём OID (суррогат) хранение в дереве вообще ничего кроме геммороя не добавит. Показывайте как вы его будете в дереве хранить :)


>>желательно со ссылкой, где это можно почитать.

Для начала вам надо освоить хотя-бы Кормена. Что бы знать почему и как Б-деревья могут вырождаться и когда они выгодны для хранения. До этой поры чего-нибудь серьёзное читать опасно - можете стать новым коллегой ЧАЛ-ом :)
18 ноя 04, 17:43    [1118154]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 U-gene

А я вот не выдержал :( Написал.
18 ноя 04, 18:08    [1118260]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
jvvjvv
Member

Откуда:
Сообщений: 56
Может кому интересным покажется....
Ссылка на статью самого основателя (и владельца) InterSystems (ну и Cache тоже).
http://www.osp.ru/cw/2000/39/024_0_print.htm

Он там, в частности, отвечает на заданный ему вопрос :"Что вы скажете относительно перспектив, не ожидает ли реляционные СУБД судьба динозавров?"
18 ноя 04, 18:17    [1118297]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Оживились, господа !

Как кто-то заметил "осеннее обострение" ?
Чувствуется, что многие углубились, наконец, в теорию баз данных. Скоро уже до троечки дотянете с моей помощью, а никто даже спасибо не сказал.
А чего уж проще: записаться на какие-нибудь курсы краткосрочные или на вечернее отделение поступить, и изучить-таки эту "проклятую" теорию баз данных. Сложного-то там особенно ничего нет, особенно если есть желание, и, тем более, если уже есть высшее образование в области реляционных баз данных.
Жаль, конечно, что мужества у sql-сообщества пока не хватает, чтобы хотя бы один, самый простой вопрос обсудить по-существу. Сразу все хватают флаги, идут на демонстрацию, и каждый, поднимаясь на трибуну, славит родную (чуть не сказал коммунистическую) партию. Проветрите немного головы, господа, и переходите из своей маргинальной организации в цивилизованное сообщество разработчиков баз данных.
Я по-прежнему готов к обсуждению поднятых вопросов:
"Роль ключей в РМД" (почуяв неладное, никто не захотел обсуждать этот вопрос в практической плоскости).
"Есть ли практическая польза от SQL" (почуяв неладное, никто не захотел обсуждать этот вопрос в практической плоскости).
Не оказывался и от обсуждения любых других вопросов, но не всех вместе, а по очереди - это ведь всем было бы удобнее...
18 ноя 04, 18:39    [1118376]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Ну ты загнул Andreww. Зачем так людей обижать...
Весь штат сотрудников IBM и Oracle.... Продавцов которым продавать, продавать, продавать тоже причисляем к гениям от компьютерной индустриии????
18 ноя 04, 18:39    [1118379]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
>>Ну ты загнул Andreww. Зачем так людей обижать...

Я вам не тыкал, заметье, ни разу.


>>Весь штат сотрудников IBM и Oracle.... Продавцов которым продавать, продавать, >>продавать тоже причисляем к гениям от компьютерной индустриии????

Надо будет рассказать знакомым инсайдейдерам, что в IBM Research работают продавцы :) В исследовательских лабораториях Oracle не в Индии где кодировщики, а в силиконовой долине тоже одни продавцы :). Бенуа Мандельброт, основатель теории фракталов, который немало времени провёл в Watson Research Center над проблемами фрактальной геометрии тоже хотел на самом деле продать пару серверов :)

Не надо коллега, боюсь у меня чего-нибудь случится со здоровьем от хохота.
18 ноя 04, 18:56    [1118427]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
с127 !

Опять "проскочил" Вашу интересную мысль про то, что я:

"Как шашкой рубанул... Такое и дураку понятно. Это вам не Кодд с заумной математикой."

То есть на самом деле Вы чего-то не поняли в ОМД ? Чего именно ? Что именно Вам хотелось бы замкнуть ?
Описание аспекта манипулирования должно "замкнуть" описание модели ?
Так Вы с ним тоже знакомы. Странная ирония...
18 ноя 04, 23:40    [1118763]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Павел Воронцов !

Оказывается я обязан сначала написать, что (цитирую Дейта, поскольку в ОМД нет понятия ключа):

"Пусть K - множество атрибутов переменной-отношения R. В этом случае множество K будет ПОТЕНЦИАЛЬНЫМ КЛЮЧОМ переменной-отношения R тогда и только тогда, когда оно обладает следующими свойствами.
а) Уникальность. Никакие допустимые значения переменной-отношения R не содержат двух различных кортежей с одинаковыми значениями атрибутов множества K.
б) Неизбыточность. Никакое из собственных подмножеств множества K не обладает свойством уникальности."

Перечитал, на всякий случай, еще раз все Ваши сообщения. Вроде бы никаких других предварительных условий не нашел. Продолжаю "бить в одну точку". Если я выбрал "неудобную точку", так и скажите. Предложите свою "точку".

Итак, о роли ключей в РМД, цепляясь за спасительную соломку - предположение Кодда...

------------------------------------------------------------------------

Пожалуйста, не скрывайте (нет же, я надеюсь, в этом никакой военной тайны), на примере Ваших приложений:

1) насколько often;
2) в каком смысле totally;
3) характерность примеров ("базовый" - part serial number);
4) о каких именно ключах (все-таки - это реляционная модель, и entity identifiers - это ключи), предположительно, идет речь:

- о "теоретических" потенциальных;
- о "практических" первичных;
- о "практических" альтернативных.

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

Было, правда несколько слабых попыток: с книгами (явная ошибка), с "ракетами" (совсем уж не убедительно) и, наконец, мировая проблема идентификации личности (о которой я сразу упомянул)...
19 ноя 04, 00:09    [1118817]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
c127
Guest
2 Андрей Леонидович

>я - инженер-механик по специальности "летательные аппараты".

Ну что ? Стыдно стало, что человек с ТАКИМ образованием объясняет Вам теорию баз данных ? А Вы еще и понять не можете, хотя, судя по всему, являетесь дипломированным специалистом в этой области.


Вы все еще не ответили на вопрос: какой ВУЗ закончили.

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

c127>"Как шашкой рубанул... Такое и дураку понятно. Это вам не Кодд с заумной математикой."

Андрей Леонидович> То есть на самом деле Вы чего-то не поняли в ОМД ? Чего именно ? Что именно Вам хотелось бы замкнуть ?
Описание аспекта манипулирования должно "замкнуть" описание модели ?
Так Вы с ним тоже знакомы.


Тут я уже вообще ничего не понял. Кого куда нужно замкнуть? "потрудитесь излагать ваши мысли яснее." (С)

Теперь отвечаю на вопрос: в ОМД я не понял ничего, поскольку не смог найти собственно модель. Реализации неизвестно чего, в простонародье называемого ОМД, вроде есть, а модели - нет. А если есть модель - дайте ссылку или сами изложите. Или что там лежит в основе CACHE. А то сравнивать нечего. Этот вопрос тоже повторяется раз в надцатый.

Ваше сравнение сводится исключительно к критике (как Вы полагаете) реляционной модели. Но это возможно только благодаря тому, что есть предмет для критики, т.е. реляционная модель, построенная Коддом или кем-то там еще. Вашей же модели нет и по этой причине ее ни ругать ни хвалить ни сравнивать с чем-либо невозможно. Так сравнения не получится независимо хороша ли РМД или нет, а получится то, что и получается - пустозвонство.
19 ноя 04, 01:52    [1118875]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Эх, была не была, обостряться - так с музыкой.
Андрей Леонидович
Павел Воронцов !

Оказывается я обязан сначала написать, что (цитирую Дейта, поскольку в ОМД нет понятия ключа):

"Пусть K - множество атрибутов переменной-отношения R. В этом случае множество K будет ПОТЕНЦИАЛЬНЫМ КЛЮЧОМ переменной-отношения R тогда и только тогда, когда оно обладает следующими свойствами.
а) Уникальность. Никакие допустимые значения переменной-отношения R не содержат двух различных кортежей с одинаковыми значениями атрибутов множества K.
б) Неизбыточность. Никакое из собственных подмножеств множества K не обладает свойством уникальности."
Ага, так Вы таки согласны с этим определением? Я правильно понял? Вот и отлично. Тогда объясните мне ещё раз медленно в чём состоит "полный провал ключей РМД"?
Андрей Леонидович
1) насколько often;
2) в каком смысле totally;
3) характерность примеров ("базовый" - part serial number);
4) о каких именно ключах (все-таки - это реляционная модель, и entity identifiers - это ключи), предположительно, идет речь:

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

1) Достаточно часто. Что тут ещё сказать я не знаю.
2) В полном смысле totally. Опять же вопрос лишен смысла. Если Вас интересует значение слов - обратитесь к словарю.
3) А при чём тут это, я не понимаю. Ну объясните мне, убогому, какой ответ Вы от меня ждёте? Что пример не характерен? Что он характерен? О чём это вообще?!
4) И те и другие и третьи помянутые Вами сущности есть суть ключи в реляционной теории, подподающие под только что помянутое определение. В РМД для них нет различия, они равнозначны. Посему ответ на Ваш вопрос - хрен знает, товарищ майор, а не всё ли равно?
Андрей Леонидович

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

Было, правда несколько слабых попыток: с книгами (явная ошибка), с "ракетами" (совсем уж не убедительно) и, наконец, мировая проблема идентификации личности (о которой я сразу упомянул)...
Ага, а я опять скажу, что Вы идеалист, батенька. Мы, убогие, по земле ходим и автоматизируем конкретные бизнес-процессы с конкретными ограничениями, логикой этого самого бизнеса накладываемые. Вы же претендуете на отражение УНИВЕРСУМА в своей базе данных. И опять скажу - нельзя объять необъятное! И опять спрошу: какому объекту реального мира соответствует объект без атрибутов? Вот это вот что/кто такое?
Object o = new Object();
??
19 ноя 04, 07:12    [1118979]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
На sql.ru нужно быть абсолютно формальным. АБСОЛЮТНО. Здесь же все математики (без иронии). А радовались, как дети. Но истина дороже. Придется отнять конфетку.

В MUMPS НЕ ИЕРАРХИЧЕСКАЯ МОДЕЛЬ ДАННЫХ.

Всего лишь СЧИТАЕТСЯ ОБЩЕПРИНЯТЫМ, что в MUMPS иерархическая модель данных, потому что там ее ЛЕГКО РЕАЛИЗОВАТЬ (как и многие другие модели).
Всего лишь очередное проявление мощи MUMPS.

Конечно, можно, но хорошо известно, что не нужно:

^a(идентификатор отдела)=список свойств отдела
^a(идентификатор отдела, идентификатор служащего)=список свойств служащего

Учебный процесс для знатоков реляционной теории, желающих познакомиться с теорией баз данных, продолжается...
19 ноя 04, 08:15    [1119031]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
dimon_n2000
тут вам надо почитать Паскаля, который алгоритм Б дерева описывает.


Я плакаль
19 ноя 04, 08:15    [1119033]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
с127 !

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

Уверяю Вас, что даже не понимая РМД (а Вы откровенно отказались от попыток ее понять), относительно легко понять ОМД, потому что она хорошо формализована, и я ее ясно изложил. Но Вам не хватило "замкнутости" (читайте внимательно хотя бы свои собственные сообщения). Всегда готов добавить, если чего-то не хватило для понимания. Чего добавить ?

P.S. Не считаю бредом то, что Вы пишете.
19 ноя 04, 08:31    [1119054]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
На счет "маргинального сообщества sql-разработчиков" тоже хорошо
Клоуны - это весело :o)
19 ноя 04, 08:44    [1119072]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Павел Воронцов !

Хороши "возражения" !
1) Мои вопросы лишены смысла.
2) Но поскольку я больной, Вы мне "ответили".
3) Я не понимаю, что ISBN в книжном бизнесе обязан быть уникальным.

Что же мы видим.
1) Опять оскорбления.
2) Выбросили ВСЕ, что было ДО этих вопросов, а теперь "не понимаете": "о чем это вообще".
3) И наконец допустили странное противоречие: все время призывали к "теории", и вдруг сказали, что я "идеалист", а Вы "автоматизируете конкретные бизнес-процессы".

Хорошо, и почему же Вы скрываете данные по применению "ключей" ?

И даже в единственном упомянутом практическом примере вроде бы отрицаете, что ISBN не может быть первичным ключом во многих "книжных" приложениях (хотя в некоторых БИЗНЕС-приложениях - может).

По-прежнему надеюсь на конструктивный диалог.
Почитайте еще раз мои выводы, которые пришлось сделать из-за отсутствия желающих сообщить о "результатах" "автоматизации конкретных бизнес-процессов".
Я же тоже "автоматизирую конкретные бизнес-процессы". И давно убедился, что НИКОГДА не следует делать идентификаторы объектов, определяемые пользователями...
19 ноя 04, 09:03    [1119105]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Andreww

1 - А я считаю. Хотя бы потому, что провожу в форуме бесплатный ликбез а мне в ответ вместо спасибо - "... вам надо почитать Паскаля который алгоритм Б-дерева (!) описывает ... ".

>>других людей я так же глупыми не считаю.
2 - Это вас украшает и выгодно отличает от коллеги ЧАЛ-а, например.

Не находите в своих высказываниях некоторого противоречия? Самокритика? Хотите поговорить об этом?

Andreww

Живой пример :

Хранение объекта типа накладная (у него как минимум есть дата,артикул,количество,цена). Если хранить его в дереве, что выбрать в какчестве идентифицирующего атрибута ? Или добавить суррогат (хорошо-хорошо OID) ? Если выбираем в качестве идентификатора артикул - выборка всех накладных за интервал дат представляет из себя обход всего дерева кроме того у артикула может быть невысокая кардинальность (об этом вам говорил vadiminfo) тогда ваше дерево превратиться в несколько связных списков. Если дату - тогда выбор всех документов для данного артикула приведёт к полному обходу дерева. И т.п. Если заведём OID (суррогат) хранение в дереве вообще ничего кроме геммороя не добавит. Показывайте как вы его будете в дереве хранить :)

Мётвый пример. Объект накладная "многомерный" (составной) (это контейнер связанный (связь = отношение – relation (англ.)) с множествами других дочерних и родительских объектов). В одном дереве его естественно хранить не нужно. (это тупо с точки зрения нормализации)

и ещё ПАВТАРЯЮ ... ПАВТАРЯЮ... ПАВТАРЯЮ (заело )
http://www.citforum.ru/database/dbguide/3-1.shtml

Будучи математиком по образованию Э.Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.)



Млять. Cache это способ хранения данных "плоских таблиц" в "иерархических списках", "деревьях" (бамбуках, баобабах, елках ... кто как спроектирует )
Логические связи между такими деревьями, какие же как в РЕЛЯЦИОННОЙ модели.
Есть избыточность... есть технология!... есть совпадение (наложение) с объектно ориентированной моделью (описанной здесь http://meta.math.spbu.ru/publication/SPB-K.pdf). Есть преимущества есть недостатки.

Называйте её как вам угодно: реляциическая, иерархиляционная, деревомумпспостобъектная, хубиквадродеревянноиерархическая. Суть от этого не изменится.
19 ноя 04, 09:07    [1119114]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Gluk (Kazan) !

Вы, пожалуй, один из немногих непредвзятых посетителей. Демонстрирующий, к тому же, неплохие знания Cache и баз данных в целом. Спасибо !
19 ноя 04, 09:08    [1119115]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Andrey K !

Вы очень близки к (недостижимой, конечно же) истине. Очень. Но немного нервничаете от того, что окружающие, как Вам кажется, не понимают каких-то "очевидных" вещей. Думаю Вам лучше, хотя бы временно, отказаться от радикальной идеи, что "любое представление данных сводится к совокупности двумерных таблиц особого вида". Тогда Вы лучше поймете MUMPS (во всяком случае).
19 ноя 04, 09:19    [1119139]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Андрей Леонидович
Думаю Вам лучше, хотя бы временно, отказаться от радикальной идеи, что "любое представление данных сводится к совокупности двумерных таблиц особого вида".

Это вы господину Э.Кодду скажите! Вам ведь виднее, с высоты "летательных аппаратов".
19 ноя 04, 09:23    [1119146]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Андрей Леонидович
3) И наконец допустили странное противоречие: все время призывали к "теории", и вдруг сказали, что я "идеалист", а Вы "автоматизируете конкретные бизнес-процессы".
Нет, батенька, я не допустил противоречия. Теория строится для описания чего-то. Конкреной области. Будучи по образованию инженером Вы вроде бы должны это понимать. Закономерности, опиывающие поведение самолёта в турбулентном потоке совсем другие, чем в ламинарном. Среда, знаете ли, накладывает ограничения. И теории там разные (хотя и на общих принципах основанные)
Андрей Леонидович

Хорошо, и почему же Вы скрываете данные по применению "ключей" ?
Вас это беспокоит? Вы хотеие поговорить об этом? Хорошо. На самом деле налицо заговор фран-масонской ложи sql-разроботчиков - маргиналов, скрывающих от Вас (и всех остальных) правду о применении "ключей". Если Вы владеете истиной - поделитесь ей! Только пожалуйста, без провалов!

Я так понял, что мои ответы Вас не удовлетворили?
Андрей Леонидович
И даже в единственном упомянутом практическом примере вроде бы отрицаете, что ISBN не может быть первичным ключом во многих "книжных" приложениях (хотя в некоторых БИЗНЕС-приложениях - может).
А в чём разница между БИЗНЕС-приложениями и просто приложениями? Я никаких других кне знаю.
Андрей Леонидович
По-прежнему надеюсь на конструктивный диалог.
Почитайте еще раз мои выводы, которые пришлось сделать из-за отсутствия желающих сообщить о "результатах" "автоматизации конкретных бизнес-процессов".
Я же тоже "автоматизирую конкретные бизнес-процессы". И давно убедился, что НИКОГДА не следует делать идентификаторы объектов, определяемые пользователями...
То есть Вы признаёте, что идентификатор объекта эквивалентен ключу? И весь сыр-бор лишь из-за того, что ключи должны быть авто-генерируемы, а не назначаемы пользователем? Так?
19 ноя 04, 09:28    [1119163]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Andrey K
и ещё ПАВТАРЯЮ ... ПАВТАРЯЮ... ПАВТАРЯЮ (заело )
http://www.citforum.ru/database/dbguide/3-1.shtml

Будучи математиком по образованию Э.Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.)



Г-н В.В. Кириллов ошибся. Отношение - не двумерная таблица. Это заблуждение, основанное на много раз виденной картинке.
19 ноя 04, 09:32    [1119174]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Павел Воронцов
Отношение - не двумерная таблица.

Согласен. Совсем не таблица. Угу а жопа это не палец угу. Только не пойму при чём здесь это и хто такой ваабще Г-н В.В. Кириллов... и в чём он ошибся?
19 ноя 04, 09:39    [1119191]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 [12] 13 14 15 16 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить