powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование БД. Два варианта реализации
7 сообщений из 7, страница 1 из 1
Проектирование БД. Два варианта реализации
    #34778770
Фотография Chop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Интересно услышать мнение...

Пример:
База данных адресов.
Возможны несколько путей реализации

Первый:
Связь соответственно один-ко-многим
Таблица1. Страны
————Код
————Наименование
Таблица2. Области
————Код
————КодСтраны
————Наименование
...
Таблица7. Квартиры
————Код
————КодУлицы
————Наименование

Второй:
Простой иерархический справочник <Адрес>
————Код
————КодРодителя
————Наименование
Для удобства и бантиков можно еще добавить поле <Уровень> и табличку <НаименованиеУровней>

Мыслишки
Принимается жестко заданное количество уровней иерархии, так что преимущества второго варианта в этом сводятся к нулю.

Второй теоретически дает несколько больший объем.
Для построения иерархий в первом случае придется строить запрос к 7-ми таблицам, во втором – рекурсию. Что быстрее?
Фильтрация, отборы?
Какие еще мысли есть по поводу преимуществ/недостатков?
...
Рейтинг: 0 / 0
Проектирование БД. Два варианта реализации
    #34779096
2b&2b
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
...
Рейтинг: 0 / 0
Проектирование БД. Два варианта реализации
    #34779123
Фотография Chop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2b&2b тынц
читал, не катит, там как раз один из вариантов решения - иерархический справочник без ограничений количества уровней, и никого не должно волновать, на каком уровне окажеться Город или Улица, был бы лишь четко задан Родитель

у меня НЕ БАЗА АДРЕСОВ
нет пропущенных родителей
тип наименования - строка одинаковой длины во всех таблицах
...
Рейтинг: 0 / 0
Проектирование БД. Два варианта реализации
    #34780017
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Chop 2b&2b тынц
читал, не катит, там как раз один из вариантов решения - иерархический справочник без ограничений количества уровней, и никого не должно волновать, на каком уровне окажеться Город или Улица, был бы лишь четко задан Родитель

у меня НЕ БАЗА АДРЕСОВЕсли в базе хранятся адреса, то это - не база(подбаза) адресов?
Chopнет пропущенных родителейМожете сказать как вам это удалось?
Вот два реальных адреса: г. Москва, ул. Фестивальная д.1
Калужская обл, Козельский р-н, д. Селедкино, д.5
Chopтип наименования - строка одинаковой длины во всех таблицахВ каких во всех?
Во всех таблицах справочников адресов?
Ну этим ограничением, кроме себя, вы никого не удивите :)

PS: по поводу одной и нескольких таблиц.
В иерархическую таблицу можно ввести поле "Уровень" и при построении адреса (без пропусков в уровнях) можно спокойно джоинить ее саму к себе, т.е. обойтись без иерархических запросов.
Так что смысл в нескольких таблицах - слабопонятен.

Кроме этого можно прочитать про иерархии и работу с ними.
...
Рейтинг: 0 / 0
Проектирование БД. Два варианта реализации
    #34783617
Фотография Chop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторЕсли в базе хранятся адреса, то это - не база(подбаза) адресов?
Еще раз повторюсь - у меня НЕ БАЗА АДРЕСОВ и там хранятся не адреса
авторВот два реальных адреса: г. Москва, ул. Фестивальная д.1
Калужская обл, Козельский р-н, д. Селедкино, д.5
очень просто:
id
id_parent
id_type
caption
Получишь ветки:
1. Город-Улица-Дом
2. Область-Район-Деревня-Дом
автор
Chopтип наименования - строка одинаковой длины во всех таблицах
В каких во всех?
Во всех таблицах справочников адресов?
Ну этим ограничением, кроме себя, вы никого не удивите :)
... смысл в нескольких таблицах - слабопонятен.
Мои данные по уровням:
1. Вид страхования
2. Правила страхования
3. Страховой продукт
4. Программа страхования
Жестко задаются законодательством и внутренними правилами компании.
Никаких "пропущенных уровней".
Никаких измений количества уровней.
Записей всех - всего несколько сотен, вводятся один раз и если у будут добвляться/меняться, то настолько редко, что даже интерфейс к этому я писать не собираюсь.

Смысла в нескольких таблицах особого я и сам не вижу, но в 1с-е, на которой работает компания это реализовано в виде отдельных справочников и от меня хотят тоже реализации в отдельных таблицах.
...
Рейтинг: 0 / 0
Проектирование БД. Два варианта реализации
    #34784291
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Несколько таблиц имеют смысл, если с разными уровнями иерархии связаны сильно разные правила обработки - например, есть еще какая-то внешняя таблица, которая имеет внешним ключом ссылку на улицу и только на улицу. В случае одной иерархической таблицы ссылочную целостность придется поддерживать руками.
...
Рейтинг: 0 / 0
Проектирование БД. Два варианта реализации
    #34784340
Фотография Chop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинНесколько таблиц имеют смысл, если с разными уровнями иерархии связаны сильно разные правила обработки - например, есть еще какая-то внешняя таблица, которая имеет внешним ключом ссылку на улицу и только на улицу. В случае одной иерархической таблицы ссылочную целостность придется поддерживать руками.
Будут внешние таблицы со ссылками...
...
Рейтинг: 0 / 0
7 сообщений из 7, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование БД. Два варианта реализации
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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