Login
Вопрос по SQL Server 2000 и foreign key
NEW 21.01.07 01:30
in Antwort scorpi_ 21.01.07 01:13
Это обычно дерево, чаще всего B-Tree.
-----
В данном случае - наполовину вырожденное.
Во-вторых вовсе не факт, что некая конкретная имплементация
индекса вообще сохраняет нулевые значения в индексе.
-------
Это подразумевает анализ _значения_ данных - маловероятно, тем более, что данные могут быть (практически) любого типа... (Но как тер.возможность - принимается).
-----
В данном случае - наполовину вырожденное.
Во-вторых вовсе не факт, что некая конкретная имплементация
индекса вообще сохраняет нулевые значения в индексе.
-------
Это подразумевает анализ _значения_ данных - маловероятно, тем более, что данные могут быть (практически) любого типа... (Но как тер.возможность - принимается).
21.01.07 03:56
Тебе объяснить, что значит B? Balanced - оно не может быть вырожденным.
Ни фига не понял.
in Antwort Murr 21.01.07 01:30
В ответ на:
В данном случае - наполовину вырожденное.
В данном случае - наполовину вырожденное.
Тебе объяснить, что значит B? Balanced - оно не может быть вырожденным.
В ответ на:
Это подразумевает анализ _значения_ данных - маловероятно, тем более, что данные могут быть (практически) любого типа...
Это подразумевает анализ _значения_ данных - маловероятно, тем более, что данные могут быть (практически) любого типа...
Ни фига не понял.
NEW 21.01.07 13:07
in Antwort scorpi_ 21.01.07 03:56
Тебе объяснить, что значит B? Balanced - оно не может быть вырожденным.
------
Ну попробуй. Правда перед этим рекомендую порыться в Кнутте. Если помню правильно - том 3-й по изданию 71-го года.
Ни фига не понял.
------
Ты говоришь, что какие-то записи могут быть неиндексированными (не включенными в индекс), при )_условии_, что _значения_ индексируемых (ключевых) полей - NULL.
------
Ну попробуй. Правда перед этим рекомендую порыться в Кнутте. Если помню правильно - том 3-й по изданию 71-го года.
Ни фига не понял.
------
Ты говоришь, что какие-то записи могут быть неиндексированными (не включенными в индекс), при )_условии_, что _значения_ индексируемых (ключевых) полей - NULL.
NEW 21.01.07 15:19
Выделываться ты можешь перед кем-нибудь другим, а если ты хочешь что-либо доказать мне, то приводи конкретные цитаты.
Какое значение? NULL это отсутствие значение, и если ты включаешь NULL в индекс, то тебе при каждом сравнении приходится делать лишние телодвижения. Кстати Oracle на самом деле не включает NULL в индекс -
in Antwort Murr 21.01.07 13:07
В ответ на:
Ну попробуй. Правда перед этим рекомендую порыться в Кнутте. Если помню правильно - том 3-й по изданию 71-го года.
Ну попробуй. Правда перед этим рекомендую порыться в Кнутте. Если помню правильно - том 3-й по изданию 71-го года.
Выделываться ты можешь перед кем-нибудь другим, а если ты хочешь что-либо доказать мне, то приводи конкретные цитаты.
В ответ на:
Ты говоришь, что какие-то записи могут быть неиндексированными (не включенными в индекс), при )_условии_, что _значения_ индексируемых (ключевых) полей - NULL.
Ты говоришь, что какие-то записи могут быть неиндексированными (не включенными в индекс), при )_условии_, что _значения_ индексируемых (ключевых) полей - NULL.
Какое значение? NULL это отсутствие значение, и если ты включаешь NULL в индекс, то тебе при каждом сравнении приходится делать лишние телодвижения. Кстати Oracle на самом деле не включает NULL в индекс -
В ответ на:
One problem with all relational databases is having the optional ability to index on a NULL column. By default, relational databases ignore NULL values (because the relational model says that NULL means "not present"). Hence, Oracle indexes will not include NULL values. http://www.dba-oracle.com/oracle_tips_null_idx.htm
One problem with all relational databases is having the optional ability to index on a NULL column. By default, relational databases ignore NULL values (because the relational model says that NULL means "not present"). Hence, Oracle indexes will not include NULL values. http://www.dba-oracle.com/oracle_tips_null_idx.htm
NEW 21.01.07 18:25
in Antwort scorpi_ 21.01.07 15:19
если ты хочешь что-либо доказать мне, то приводи конкретные цитаты.
------
Для этого надо искать Кнута - под руками его нет. Да и не требуется - Деревья, двоичные, сбалансированные предполагают что их можно сбалансировать. При одинаковых значениях балансировка не получается и придумываются различные расширения... Вообщем - посмотри у Кнута условия применимости...
Hence, Oracle indexes will not include NULL values.
------
Хммм... буду знать, что под Ораклом возможны проблемы с non-enforced реляциями...
------
Для этого надо искать Кнута - под руками его нет. Да и не требуется - Деревья, двоичные, сбалансированные предполагают что их можно сбалансировать. При одинаковых значениях балансировка не получается и придумываются различные расширения... Вообщем - посмотри у Кнута условия применимости...
Hence, Oracle indexes will not include NULL values.
------
Хммм... буду знать, что под Ораклом возможны проблемы с non-enforced реляциями...
NEW 21.01.07 18:57
Во-первых они не обязательно двоичные, во-вторых они не предполагают, они гарантируют сбалансированность после каждой операции.
Я уже сказал - без конкретных возражений или цитат я и дальше буду считать тебя просто болтуном.
in Antwort Murr 21.01.07 18:25
В ответ на:
Да и не требуется - Деревья, двоичные, сбалансированные предполагают что их можно сбалансировать. При одинаковых значениях балансировка не получается и придумываются различные расширения...
Да и не требуется - Деревья, двоичные, сбалансированные предполагают что их можно сбалансировать. При одинаковых значениях балансировка не получается и придумываются различные расширения...
Во-первых они не обязательно двоичные, во-вторых они не предполагают, они гарантируют сбалансированность после каждой операции.
В ответ на:
Вообщем - посмотри у Кнута условия применимости...
Вообщем - посмотри у Кнута условия применимости...
Я уже сказал - без конкретных возражений или цитат я и дальше буду считать тебя просто болтуном.
NEW 21.01.07 21:13
in Antwort scorpi_ 21.01.07 18:57
они гарантируют сбалансированность после каждой операции.
-------
Дерево балансируется после определения положения нового элемента. И именно *предполагается* что положение элемента можно определить однозначно, что, однако, достижимо не всегда.
Заданные ключи:
1. аааааа
2. аааааа
3. аааааа
Приведи дерево и обоснуй почему оно такое. Детали найдешь именно там где было указано - Кунут, т3, 6.2.3. Сбалансированные деревья.
-------
Дерево балансируется после определения положения нового элемента. И именно *предполагается* что положение элемента можно определить однозначно, что, однако, достижимо не всегда.
Заданные ключи:
1. аааааа
2. аааааа
3. аааааа
Приведи дерево и обоснуй почему оно такое. Детали найдешь именно там где было указано - Кунут, т3, 6.2.3. Сбалансированные деревья.
21.01.07 21:32
При чём тут однозначность? B-дерево всегда полностью сбалансировано. Как будут расположены одинаковые ключи абсолютно никого не волнует. Вообще мне кажется, что ты путаешь B-tree и binary search tree.
in Antwort Murr 21.01.07 21:13, Zuletzt geändert 21.01.07 21:36 (scorpi_)
В ответ на:
И именно *предполагается* что положение элемента можно определить однозначно, что, однако, достижимо не всегда.
И именно *предполагается* что положение элемента можно определить однозначно, что, однако, достижимо не всегда.
При чём тут однозначность? B-дерево всегда полностью сбалансировано. Как будут расположены одинаковые ключи абсолютно никого не волнует. Вообще мне кажется, что ты путаешь B-tree и binary search tree.
NEW 21.01.07 22:41
in Antwort scorpi_ 21.01.07 21:32
B-дерево всегда полностью сбалансировано.
------
В свое время я "переводил" кнутовское описание в сишный код. Там есть вполне определенное условие сохранения сбалансированности дерева. Нарушение этого условия непозволяет иметь сбалансированное дерево. Любой вариант обхода этого ограничения предполагает какую-либо специализированную обработку "листьев", содержащих более одного элемента.
Вообще мне кажется, что ты путаешь B-tree и binary search tree.
------
В смысле - организованную хранимую структуру и аналогичный метод? - это врядли, я еще не настолько пьян...
------
В свое время я "переводил" кнутовское описание в сишный код. Там есть вполне определенное условие сохранения сбалансированности дерева. Нарушение этого условия непозволяет иметь сбалансированное дерево. Любой вариант обхода этого ограничения предполагает какую-либо специализированную обработку "листьев", содержащих более одного элемента.
Вообще мне кажется, что ты путаешь B-tree и binary search tree.
------
В смысле - организованную хранимую структуру и аналогичный метод? - это врядли, я еще не настолько пьян...
NEW 22.01.07 00:49
Вот для BST как раз и возможны случаи с линейной зависимостью. Для B-дерева - нет.
ОК, я уже понял, что ты не знаешь, что такое B-дерево. Сравни - http://en.wikipedia.org/wiki/B-tree и http://en.wikipedia.org/wiki/Binary_search_tree
in Antwort Murr 21.01.07 22:41
В ответ на:
В свое время я "переводил" кнутовское описание в сишный код. Там есть вполне определенное условие сохранения сбалансированности дерева. Нарушение этого условия непозволяет иметь сбалансированное дерево. Любой вариант обхода этого ограничения предполагает какую-либо специализированную обработку "листьев", содержащих более одного элемента.
В свое время я "переводил" кнутовское описание в сишный код. Там есть вполне определенное условие сохранения сбалансированности дерева. Нарушение этого условия непозволяет иметь сбалансированное дерево. Любой вариант обхода этого ограничения предполагает какую-либо специализированную обработку "листьев", содержащих более одного элемента.
Вот для BST как раз и возможны случаи с линейной зависимостью. Для B-дерева - нет.
В ответ на:
В смысле - организованную хранимую структуру и аналогичный метод?
В смысле - организованную хранимую структуру и аналогичный метод?
ОК, я уже понял, что ты не знаешь, что такое B-дерево. Сравни - http://en.wikipedia.org/wiki/B-tree и http://en.wikipedia.org/wiki/Binary_search_tree