|
|
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
mcureenab _модНаличие или отсутствие иерархии закладывается на уровне концептуальной модели данных, и лишь затем реализуется в СУБД, интерфейсах, отчетах и пр. Пмсм, автор топика именно это имел ввиду. Т.е., если иерархия изначально не заложена, то потом уже будет поздно, ничего не изменишь. Если её нет в исходных данных, тогда да, но опять же, если мы можем построить B*Tree индекс, то автоматически получаем некоторую иерархическую структуру, пусть даже бессмысленную с прикладной точки зрения. А если есть, то даже если мы специально не закладывали иерархические связи в модель данных, иерархию можно будет построить когда угодно. IMHO B*Tree нельзя построить (бессмысленен) не на пространственных (изначально иерархических) данных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2008, 09:36 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
mcureenabдаже если мы специально не закладывали иерархические связи в модель данных, иерархию можно будет построить когда угодно. Вот это и вызывает большие сомнения - может лучше перезаложиться сразу, чтоб потом не переделывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2008, 09:40 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
_мод mcureenabдаже если мы специально не закладывали иерархические связи в модель данных, иерархию можно будет построить когда угодно. Вот это и вызывает большие сомнения - может лучше перезаложиться сразу, чтоб потом не переделывать. Так переделывать ничего не нужно. Берём имеющиеся данные, и представляем их (там... в форме или отчёте) в иерархическом виде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2008, 19:54 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
Всех с прошедшим праздником! 2 mcureenab > Почти любую таблицу можно преобразовать в древовидную структуру, например можно скопировать её в индексно организованную таблицу, тем самым обеспечив хранение данных в виде древовидной структуры. Вот можно пример, как это сделать в Access? > Если её нет в исходных данных, тогда да, но опять же, ЕСЛИ мы можем построить B*Tree индекс, то автоматически получаем некоторую иерархическую структуру, пусть даже бессмысленную с прикладной точки зрения. 2 _мод > Пмсм, автор топика именно это имел ввиду. Ага. > Т.е., если иерархия изначально не заложена, то потом уже будет поздно, ничего не изменишь. Можно, но много делать. > Вот это и вызывает большие сомнения - может лучше перезаложиться сразу, чтоб потом не переделывать. Ага ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2008, 06:48 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
КД2 mcureenab > Почти любую таблицу можно преобразовать в древовидную структуру, например можно скопировать её в индексно организованную таблицу, тем самым обеспечив хранение данных в виде древовидной структуры. Вот можно пример, как это сделать в Access? Можно ли это сделать конкретно в Access'е не знаю. Это было очень давно. В оракле имеем DDL: Код: plaintext В результате получаем таблицу, в которой записи физически храняться в виде иерархии блоков БД, которая отражает порядок записей в PK. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2008, 21:27 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
mcureenab IMHO это не то. Мы говорим о пользовательских данных, а не о методах быстрого доступа к плоскому столбцу в Oracle авторИндекс-таблицы Индекс-таблица — это таблица, которая физически построена в виде двоичного дерева относительно своего первичного ключа. Oracle, начиная с версии 6, допускает возможность не производить чтение блоков данных таблицы в тех случаях, когда в запросах на выборку данных используются только столбцы индекса. Однако при операциях добавления, обновления и удаления записей обязательно должна была участвовать основная таблица. Начиная с Oracle8, существует возможность определить таблицу, которая одновременно является и собственным индексом, что устраняет ведение двух отдельных структур. Как правило, это таблицы с короткими строками, обращение, к которым всегда производится или по первичному ключу, или полным сканированием. Не рекомендуется использовать индекс-таблицы, если строки имеют относительно большую длину, например, свыше 20% от размера блока. В этом случае лучшим выбором является использование обычных таблиц и индексов. Для создания индекс-таблиц в предложении CREATE TABLE указываются ключевые слова ORGANIZATION INDEX. Пример создания индексно-организованной таблицы представлен в листинге 232. SQL> CREATE TABLE TabIndex 2 (At1 NUMBER PRIMARY KEY, 3 At2 VARCHAR2(40)) 4 ORGANIZATION INDEX; Table created. ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2008, 09:39 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
Petro123 mcureenab IMHO это не то. Мы говорим о пользовательских данных, а не о методах быстрого доступа к плоскому столбцу в Oracle авторИндекс-таблицы ... Так и я индекс-таблицу не с потолка взял, а построил из пользовательских данных. Причём что касается СУБД Оракл, это один из немногих случаев, когда данные физически храняться в иерархическом виде, а не в куче. Пример индекс-таблицы иллюстрирует и тот факт, что иерархические конструкции можно построить на любых данных и для этого нет нужды описывать дополнительные колонки в таблицах и т.п. Наконец, Кнут в "Искусстве программирования" разродился главой о деревьях. Пойду почитаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2008, 11:29 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35174493&tid=1543998]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
93ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 245ms |
| total: | 418ms |

| 0 / 0 |
