ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Древовидная структура - панацея?
16 сообщений из 16, страница 1 из 1
Древовидная структура - панацея?
    #34008633
parovoZZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
parovoZZ
Участник
Привет

Допустим, надо указать адрес какого-то объекта. Отображаем в виде

Страна -> город -> улица -> дом -> квартира

Можно создать таблицу типа

Квартира
(Дом_ID,
Улица_ID,
Город_ID,
Страна_ID)

где ID ссылаются на соответствующие таблицы с данными о том или ином элементе. А что делать, если надо произвольно сгруппировать какие-либо элементы? Например, cтраны по размещению на континентах, города на северные и южные, областные центры и столицы и т.д. Тогда при произвольном количестве элементов группировки (группа -> город -> или группа -> группа -> город ->) предыдущая таблица не годится. Надо создать таблицу вида

Tree
(ID,
Элемент_ID,
Таблица,
parent_ID)

Здесь parent_ID ссылается на ID. Элемент_ID ссылается на таблицу, указанную в поле "Таблица" (признак группировки никуда не ссылается - он не несёт никакой информации кроме как признака). Вопрос в следующем: как в таком случае обеспечить целостность БД? Ведь Элемент_ID ссылается не одновременно на три разных таблицы. Может есть ещё какой-то способ это реализовать? Пока что идея использовать сразу две вышеприведённые таблицы + триггеры для вставки.
...
Рейтинг: 0 / 0
25.09.2006, 03:14
| Ответить | Цитировать | Написать  
Древовидная структура - панацея?
    #34009330
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
Есть ощущение, что происходит путаница между уровнем модели БД и уровнем визуального представления в приложении. Вы вроде как хотите, чтобы структура БД каким-то образом полностью соответствовала интерфейсу программы. Обычно это тупиковый путь.
Вы главное правильно БД спроектируйте, а как данные отображать -- дело техники: хошь такое дерево, хошь такой список...
С точки зрения проектирования БД не ясны ваши проблемы. Задача вроде не очень трудная.
...
Рейтинг: 0 / 0
25.09.2006, 12:12
| Ответить | Цитировать | Написать  
Древовидная структура - панацея?
    #34009562
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
автор
Квартира
(Дом_ID,
Улица_ID,
Город_ID,
Страна_ID)


Для начала хорошо бы определиться с методом хранения адресной информации.
Или
Квартира (Кв_ID, Дом_ID)
Дом (Дом_ID,Улица_ID)
...

или
АдресныйОбъект (Адр_объект_ID,тип, входит_в_ID)


Группировка же ортогональна адресам. Например для второго варианта

Входит_в_Группу (Адр_объект_ID, Группа_ID).

Что из себя представляют группы также вопрос отдельный.

Посмотрите на КЛАДР.
...
Рейтинг: 0 / 0
25.09.2006, 13:24
| Ответить | Цитировать | Написать  
Древовидная структура - панацея?
    #34010360
parovoZZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
parovoZZ
Участник
Ну смотрите. Возьмём к примеру файловую систему. Есть файлы, есть приложения, которыми эти файлы открываются. Соответственно есть таблицы с файлами, есть разные таблицы с приложениями. Надо сделать так, чтобы не возможно было удалить приложение, пока есть для него файлы. Грубо говоря запись из этой категории файлов ссылается на таблицу с соответ. приложением.
Файлы с одним расширением я могу сгруппировать в одну папку. Эту папку могу вложить ещё в одну папку. А могу и не вкладывать, т.е. чёткой глубины вложенности нет (как вариант, можно ограничить уровень вложенности от 0 до 2-х - тогда задача в корне упростится).
Вопрос в том, как в базе данных сохранить путь от элемента высшего (первого) уровня к низшему (третьего) при наличии таких вот папок? Обеспечив при этом ещё и целостность.
...
Рейтинг: 0 / 0
25.09.2006, 16:24
| Ответить | Цитировать | Написать  
Древовидная структура - панацея?
    #34010824
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Ээ... так адреса или папки? Приложения связаны с файлами или типами файлов?
Собственно аккуратное перечисление сущностей и связей это уже почти ответ.
...
Рейтинг: 0 / 0
25.09.2006, 18:22
| Ответить | Цитировать | Написать  
Древовидная структура - панацея?
    #34013814
parovoZZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
parovoZZ
Участник
И адреса, и папки. Вопрос в том, как обеспечить ссылочную целостность. Вот если бы из всех таблиц сделать одну со сквозной нумерацией. Но тогда Города и улицы и дома свалятся в одну кучу. Чего делать не надо. Пока только один вариант - из первого поста. НО. Избыточность.
...
Рейтинг: 0 / 0
26.09.2006, 18:55
| Ответить | Цитировать | Написать  
Древовидная структура - панацея?
    #34013848
parovoZZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
parovoZZ
Участник
Ну вообщем, пикча. Сверху - это то, что есть сейчас, снизу - должна быть такая возможность. При этом элементы Северные и Южные районы, Чётная сторона для выбора пользователю не доступны (признак группировки элементов одного уровня).
...
Рейтинг: 0 / 0
26.09.2006, 19:21
| Ответить | Цитировать | Написать  
Древовидная структура - панацея?
    #34013887
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Структура базы и визуальный интерфейс единственно не должны друг другу противоречить. А вычислить одно по другому сложновато будет. Дерево для отображения может строится запросом как из одной так и нескольких таблиц.
Добавление/изменени узла также может затрагивать одну или несколько или разные таблицы в БД.

Опишите сущности и их отношения что называется по жизни.
Например, может /обязана улица входить в несколько / только одну группу.
Или же в группу входят совсем не улицы а дома. (Улица пересекает несколько районов).
...
Рейтинг: 0 / 0
26.09.2006, 19:55
| Ответить | Цитировать | Написать  
Древовидная структура - панацея?
    #34013943
parovoZZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
parovoZZ
Участник
В группе, конечно, не один элемент, а несколько. И город, и улица, и дом - всё должно иметь возможность быть сгруппировано по определённому признаку (чтобы пользователь мог как можно быстрее добраться до нужного дома).Но, к примеру, в городе может быть всего одна улица, которая нас интересует. Для неё вводить группу бессмысленно.
Вот если бы в FK можно было задать три таблицы на выбор - вопроса вообще б не было.
...
Рейтинг: 0 / 0
26.09.2006, 20:43
| Ответить | Цитировать | Написать  
Древовидная структура - панацея?
    #34014598
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
parovoZZВот если бы в FK можно было задать три таблицы на выбор - вопроса вообще б не было. http://www.sql.ru/forum/actualthread.aspx?tid=294893#2679780Здесь, но вопрос в другом, так возможно?
-Город
--Районы по географии
---Северные
----Улица1
---Южные
----Улица1
--Районы по роли
---Спальные
----Улица1
---Деловые
----Улица1
--Улицы по типу
---Проспект
...
---Улица
----Улица1
...
Рейтинг: 0 / 0
27.09.2006, 10:15
| Ответить | Цитировать | Написать  
Древовидная структура - панацея?
    #34017055
parovoZZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
parovoZZ
Участник
НЕ, есть три таблицы

Города
Улицы
Дома


Всё. Соответственно
-Город
--Улица1
--Улица2
--Улица3

....

Такого быть не должно, иначе будет путаница
-Город
--Улица1
--Улица1

.....

Только так

-Город
--Улица1
--Улица2


-Город
--Улица1
--Улица3

...

Как пользователь будет это группировать - никому не известно. Как ему удобнее. Главное, что группировка несёт ТОЛЬКО визуальную нагрузку.

К примеру, на вокзале есть два павильона - Отправление и Прибытие. Нумерация помещений не сквозная.

Можно так

-Вокзал[Отправление]
--пом 101
--пом 210
--Зал ожидания

-Вокзал[Прибытие]
--Зал ожидания

...


Но лучше так
-Вокзал
--Прибытие
---Зал ожидания


--Отправление
---пом 101
---Зал ожидания

...

Для этого есть таблица

Дерево
(ID ,
Элемент_ID ,
Имя_таблицы,
parent_ID);

Имя таблицы - это та таблица, на которую ссылается Элемент_ID. Так как таблиц много, FK не поможет. Только на триггерах. А хотелось бы на физическом уровне.
...
Рейтинг: 0 / 0
27.09.2006, 19:38
| Ответить | Цитировать | Написать  
Древовидная структура - панацея?
    #34024469
okdoky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
okdoky
Участник
parovoZZПривет

Допустим, надо указать адрес какого-то объекта. Отображаем в виде

Страна -> город -> улица -> дом -> квартира

Можно создать таблицу типа

Квартира
(Дом_ID,
Улица_ID,
Город_ID,
Страна_ID)

где ID ссылаются на соответствующие таблицы с данными о том или ином элементе. А что делать, если надо произвольно сгруппировать какие-либо элементы? Например, cтраны по размещению на континентах, города на северные и южные, областные центры и столицы и т.д. Тогда при произвольном количестве элементов группировки (группа -> город -> или группа -> группа -> город ->) предыдущая таблица не годится. Надо создать таблицу вида

Tree
(ID,
Элемент_ID,
Таблица,
parent_ID)

Здесь parent_ID ссылается на ID. Элемент_ID ссылается на таблицу, указанную в поле "Таблица" (признак группировки никуда не ссылается - он не несёт никакой информации кроме как признака). Вопрос в следующем: как в таком случае обеспечить целостность БД? Ведь Элемент_ID ссылается не одновременно на три разных таблицы. Может есть ещё какой-то способ это реализовать? Пока что идея использовать сразу две вышеприведённые таблицы + триггеры для вставки.
Вы ушли от главного принципа реляционных моделей, нормализации. Поэтому возникли проблемы, с избыточностью, с целостностью. Для представления древовидной структуры Страна -> город -> улица -> дом -> квартира можно было использовать 4 таблицы. Например:
Код: plaintext
страна  <>---*   город  <>---*  улица  <>---*  дом

Надеюсь, если Вы знаете UML, обозначения <>---* понятны. Например, соответственно, таблица "город" будет выглядеть так:
Код: plaintext
1.
2.
3.
город
ид_город
имя
ид_страна

Для группирования городов, стран, улиц, домов также лучше использовать отдельные таблицы. Например, связь город -> район -> улица
Код: plaintext
город  <>---*  район  <>---* улица

На Zigzag все эти деревья реализуются проще. Заранее схему таблиц можно не указывать. Ну и конечно дерево, само по себе поддерживает целостность. Вы не можете удалить верхнюю вершину, не удалив нижнюю.
...
Рейтинг: 0 / 0
01.10.2006, 13:21
| Ответить | Цитировать | Написать  
Древовидная структура - панацея?
    #34027073
parovoZZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
parovoZZ
Участник
Читал я про зигзаг. Неоднозначное впечатление.


Вообщем, накумекал так. К каждой из 3-х таблиц (дом, улица, город) добавляется ещё одна (tree_*) с деревом группировки. Тогда у таблицы

Дом
(Улица_ID,
Город_ID)

добавятся ещё три поля со ссылками на начальный ID группы из этих таблиц. Соответственно в таблице, например, tree_улица поле parent_ID со значением 0 будет означать высший уровень. Что сохраняется. Связи элементов можно отображать в произвольном порядке, при этом признаки группировки элементов будут прежними (Улица -> Город -> Дом), а не привязаны друг к другу. Из таблиц tree_* внешних ключей нет, соответственно никаких забот о сохранении целостности нет. Всё реализовано в таблице Дом.
...
Рейтинг: 0 / 0
02.10.2006, 19:48
| Ответить | Цитировать | Написать  
Древовидная структура - панацея?
    #34029071
okdoky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
okdoky
Участник
parovoZZ : Странный у Вас подход и не очень понятный. До этого предлагали использовать имя таблицы в качестве атрибута. Что обычно не принято в РБД-приложениях. Для РБД имена таблиц и атрибутов заранее известны приложениям. Для нашей задачи последнее тоже не подходило, поэтому и использовался Zigzag, где вообще отсутствуют имена таблиц, а имена атрибутов можно получить даже по их значениям.

Что Вы сейчас предполагаете задавать в таблице tree_город? Такую зависимость "город -> улица"?
...
Рейтинг: 0 / 0
03.10.2006, 15:25
| Ответить | Цитировать | Написать  
Древовидная структура - панацея?
    #34029111
okdoky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
okdoky
Участник
Неправильно выразился, хотя по контексту должно быть понятно. Вместо "До этого предлагали использовать имя таблицы в качестве атрибута" лучше написать "До этого предлагали использовать имена таблиц в качестве значений атрибутов".
...
Рейтинг: 0 / 0
03.10.2006, 15:34
| Ответить | Цитировать | Написать  
Древовидная структура - панацея?
    #34030090
parovoZZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
parovoZZ
Участник
okdoky parovoZZ :

Что Вы сейчас предполагаете задавать в таблице tree_город? Такую зависимость "город -> улица"?

В tree_город будет дерево групп. Т.е. группа -> группа -> ... группа -> Город_ID. Группа, у которой parent_ID = 0 будет последней в этом дереве. Дочерним элементом какого узла она будет - прописано в таблице Дом (на что указывает город_ID). И таких таблиц будет 3. И никаких имён таблиц в атрибутах (от чего я хотел так избавиться), только в запросах.
...
Рейтинг: 0 / 0
03.10.2006, 21:39
| Ответить | Цитировать | Написать  
16 сообщений из 16, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Древовидная структура - панацея?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=34027073&tid=1545005]:
 0ms
get settings:
 6ms
get forum list:
 11ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 156ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 33ms
get tp. blocked users:
 1ms
others: 204ms
total:  424ms
созд. / загр.: 424ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]