powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Структура БД
65 сообщений из 65, показаны все 3 страниц
Структура БД
    #34358427
dimichis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Проектирую структуру БД Подписок на различные журналы. С некоторой частью помогли разобраться в саседнем форуме "Access".
1) Интересует таблица "Списки_Мероприятий" верный ли я подход использовал для реализации идеи что физическое лицо может посетить несколько мероприятий (Конгресс, Форум, Симпозиум итд.)?

2) Интересует таблица "Адреса". Что-то много справочников получается у этой таблицы или как-то можно подругому сгрупировать поля?

3)Может есть какие нибудь еще недочеты, мнения, критика.
Взаранее спасибо.
...
Рейтинг: 0 / 0
Структура БД
    #34358454
dimichis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Наверно слишком мелко получилось вот покрупней.
...
Рейтинг: 0 / 0
Структура БД
    #34358455
Фотография Rin@t
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бегло просмотрев.... Ума не приложу, зачем нужны справочники типов (городов, областей, улиц). Что это такое?
...
Рейтинг: 0 / 0
Структура БД
    #34358475
dimichis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть тип города (Город, деревня, село, послелок итд).
Есть тип области (Область, край , Автономный округ итд) разьве не надо их выносить в справочник чтобы подставлять их а не забивать вручную каждый раз.
...
Рейтинг: 0 / 0
Структура БД
    #34358500
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimichisЕсть тип города (Город, деревня, село, послелок итд).
Есть тип области (Область, край , Автономный округ итд) разьве не надо их выносить в справочник чтобы подставлять их а не забивать вручную каждый раз.гм. согласно кладру могет быть нас.пункт приписан к городу. : (..р-н, мухосранск г, пупкино п (или мкр), чесалова ул...)т.ч. видимо надоть

...городнас пунктулица
с другой - т.к. у вас есть справочник городов и улитц, то повторение полей типов и в справочнике (улиц/нас пунктов) и в Адресе - избыточно. Что, кстати сказать, чревато. Т.ч. предлагаю в "адресе" поля типов убить.
...
Рейтинг: 0 / 0
Структура БД
    #34358509
Фотография Rin@t
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimichisЕсть тип города (Город, деревня, село, послелок итд).
Смесь бульдога с носорогом :-). Imho вернее использовать термин "тип населённого пункта". И в адресе (Адреса) их указывать не надо - очевидная избыточность. Тип населённого пункта привязывается к населённому пункту.

dimichisЕсть тип области (Область, край , Автономный округ итд) разьве не надо их выносить в справочник чтобы подставлять их а не забивать вручную каждый раз.
Выносить надо. Также как понимать, что это агрегаты: насёленные пункты (Город, деревня, село, поселок) являются принадлежностью областей, краёв, округов.
...
Рейтинг: 0 / 0
Структура БД
    #34358523
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
что еще не понятно:
у вас один контрагент имеет множественное представительство и в ЮрЛицах и в ФизЛицах. Так и должно быть? или вы просто не умеете задавать связь 1:1?
...
Рейтинг: 0 / 0
Структура БД
    #34358557
dimichis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
4321что еще не понятно:
у вас один контрагент имеет множественное представительство и в ЮрЛицах и в ФизЛицах. Так и должно быть? или вы просто не умеете задавать связь 1:1?

Контрагент может быть 1)Юредическим лицом рабочий адрес, 2)Физическим лицом домашний адрес, 3)Физическим лицом на рабочий адрес юридического лица (т.е. где он работает) 4) И вообще просто человек, почтальен, курьер итд. Именно такой вариант мне посаветовали на соседнем форуме "Access".
...
Рейтинг: 0 / 0
Структура БД
    #34358560
Фотография Rin@t
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Информацию о банках необходимо выделить в отдельную таблицу.
...
Рейтинг: 0 / 0
Структура БД
    #34358591
dimichis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Rin@tИнформацию о банках необходимо выделить в отдельную таблицу.

Спасибо. Предпологал это делать.
...
Рейтинг: 0 / 0
Структура БД
    #34358661
dimichis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Често говоря так и непонял что делать с типами.
Как удалить непойму. В поле город будет введено (Москва, Пушкино без всяких г.Москва, п.Пушкино), поэтому и делаю тип города, области, улици итд. Можно поподробнее с примерчиком или схемкой как данные будут храниться.
...
Рейтинг: 0 / 0
Структура БД
    #34358718
Фотография shelsoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По поводу адресов
- есть такая штука "ОКАТО" - Общеросийский классификатор админ.-терр. деления
- есть такая штука "ОКСМ" - Общеросийский классификатор стран мира
- есть такая штука "Адресная система" - енто в налоговую МНС
посмотрите - появятся трезвые мысли по поводу адресов ...

_________________________________________________________________________________
... Как что достать - вторая эскадрилья. А как самолеты сбивать - первая эскадрилья ...
...
Рейтинг: 0 / 0
Структура БД
    #34359453
Фотография Rin@t
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimichisЧесто говоря так и непонял что делать с типами.
Как удалить непойму. В поле город будет введено (Москва, Пушкино без всяких г.Москва, п.Пушкино), поэтому и делаю тип города, области, улици итд. Можно поподробнее с примерчиком или схемкой как данные будут храниться.
Таблица "Города" должна быть связана с таблицей "Типы городов" (настоятельно рекомендую заменить название таблицы "Города" на "Населённые пункты", "Типы городов" на "Типы населённых пунктов". Названия "Города" и "Типы городов" применительно к вашей БД выглядят нелепо).

Аналогично устанавливаются связи и для других пар таблиц.
...
Рейтинг: 0 / 0
Структура БД
    #34359627
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> 1) Интересует таблица "Списки_Мероприятий" верный ли я подход использовал
> для реализации идеи что физическое лицо может посетить несколько мероприятий

При условии, что они не проходят в одно и то же время.

> 2) Интересует таблица "Адреса". Что-то много справочников получается у этой таблицы
> или как-то можно подругому сгрупировать поля?

Здесь все плохо. Нормализуйте основную таблицу. Используйте отдельно административное и отдельно территориальное деление. Избавьтесь от лишних типов.

> 3)Может есть какие нибудь еще недочеты, мнения, критика.

Никакая схема. Поработаете с ней - поймете, почему.
...
Рейтинг: 0 / 0
Структура БД
    #34359668
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimichisЧесто говоря так и непонял что делать с типами.
Как удалить непойму. В поле город будет введено (Москва, Пушкино без всяких г.Москва, п.Пушкино), поэтому и делаю тип города, области, улици итд. Можно поподробнее с примерчиком или схемкой как данные будут храниться.

Сейчас во многих организациях используется так называемый общероссийский классификатор адресов (КЛАДР). Либо напрямую, либо данные из него загружаются. Этот классификатор содержит официальный способ адресации. Очень рекомендую ознакомится с его устройством (в любом поисковике набираете "КЛАДР"), так как если ваша разработка будет практически использоваться то вероятность, что связываться с классификатором потребуется достаточно высока.
...
Рейтинг: 0 / 0
Структура БД
    #34359729
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Этот классификатор содержит официальный способ адресации.

Да ну? В Российской Федерации служебные документы ФНС уже имеют силу законов? Чуши не пишите, пожалуйста.
...
Рейтинг: 0 / 0
Структура БД
    #34359865
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Этот классификатор содержит официальный способ адресации.

Да ну? В Российской Федерации служебные документы ФНС уже имеют силу законов? Чуши не пишите, пожалуйста.

А где вы в моем посте слово "закон" увидели? На всякий случай (если у вас трудности с языком) выдержка:
толковый словарь русского языкаОФИЦИАЛЬНЫЙ прил. -
Правительственный или должностной. // Исходящий от правительственных органов или должностных лиц.
Вы хотите сказать, что ФНС (а также пенсионный фонд, например) не является правительственным органом?
...
Рейтинг: 0 / 0
Структура БД
    #34359998
Фотография Rin@t
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 guest_20040621 & Bogdanov Andrey:
да ладно вам спорить, отклонившись от темы топика. Схема, предложенная для обсуждения, - тихий ужас.
"Нормализуйте основную таблицу" - очень хорошее предложение. Знает ли автор об этом? В сети немало материалов.
...
Рейтинг: 0 / 0
Структура БД
    #34360121
dimichis 4321что еще не понятно:
у вас один контрагент имеет множественное представительство и в ЮрЛицах и в ФизЛицах. Так и должно быть? или вы просто не умеете задавать связь 1:1?

Контрагент может быть 1)Юредическим лицом рабочий адрес, 2)Физическим лицом домашний адрес, 3)Физическим лицом на рабочий адрес юридического лица (т.е. где он работает) 4) И вообще просто человек, почтальен, курьер итд. Именно такой вариант мне посаветовали на соседнем форуме "Access".йопта.
Вы читаете, что вам пишут?
Вы хотя бы читаете то, что сами цитируете?
Итак вы пишете:
контрагент у вас может быть.
при этом он может быть лицом.

когда он сможет быть лицами, а не лицом, тогда и будете устанавливать связь 1:допупа, пока же вас устроит связь 1:1 (как ее установить в аксе - спросите в форуме акса).

а то, что контрагент могет иметь массу адресов, описывается не связями контрагент-лицо, а связями контрагент-...-адрес (у вас связь опосредована еще и некой книгой)


================================================================
касательно типа города в адресе:
скажем есть 2 адреса, в которые входит некий (один и тот же) город мухосранск. Причем в первый адрес он входит как "город", а в другой - как "поселок городского типа". Это ваша схема позволяет. Так правильно ли это? Или свойство мухосранска быть деревней это таки св-во мухосранска, а не св-во некоего адреса, в который мухосранску не повезло попасть?
(то же и по прочим вхождениям "типов" в адрес, а не в объект, тип которого они задают)
...
Рейтинг: 0 / 0
Структура БД
    #34360311
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
4321т.к. у вас есть справочник городов и улитц, то повторение полей типов и в справочнике (улиц/нас пунктов) и в Адресе - избыточно. Что, кстати сказать, чревато. Т.ч. предлагаю в "адресе" поля типов убить.Не, города и улицы устроены у автора по-разному. Улицы - это 98% справочник имен улиц - типа ул./проспект Иванова/1-го мая и комбинируй на здоровье.
Города содержат индивидуализирующие атрибуты и видимо это истинно города а не имена. так что тип города уместен в городе, а не адресе.
В КЛАДР типы присутсвуют отдельным полем и таблицей, причем по уровням.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
1	АО	Автономный округ	101
1	Аобл	Автономная область	102
1	г	Город	103
1	край	Край	104
1	обл	Область	105
1	Респ	Республика	106
2	р-н	Район	201
2	тер	Территория	203
2	у	Улус	202
3	волость	Волость	310
3	г	Город	301
...
Рейтинг: 0 / 0
Структура БД
    #34360377
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimichisКонтрагент может быть 1)Юредическим лицом рабочий адрес, 2)Физическим лицом домашний адрес, 3)Физическим лицом на рабочий адрес юридического лица (т.е. где он работает) 4) И вообще просто человек, почтальен, курьер итд. Именно такой вариант мне посаветовали на соседнем форуме "Access".Тогда проще связать их прямо по первичным ключам КонтрнагентИД==ЮрлицоИД, КонтрнагентИД==ЮрлицоИД. КонтрагентКод в Юрлицах и Физлицах лишний. Или это специфика Access?
...
Рейтинг: 0 / 0
Структура БД
    #34360429
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bogdanov Andrey, понял, вычеркиваю. Словари цитируйте девочкам с Тверской.

Остальным: нафига, объясните, пожалуйста, использовать в свой работе чью-то говенную поделку (я имею в виду КЛАДР) с абсолютно идиотской структурой данных только потому, что она есть? Ну тупость же невероятная: добровольно тащить в свою базу данных кусок дерьма, спроектированный пьяным китайским школьником, плюс все ошибки блондинок-операторов.
...
Рейтинг: 0 / 0
Структура БД
    #34360567
Фотография shelsoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"Остальным: нафига, объясните, пожалуйста, использовать в свой работе чью-то говенную поделку"

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

_________________________________________________________________________________
... Как что достать - вторая эскадрилья. А как самолеты сбивать - первая эскадрилья ...
...
Рейтинг: 0 / 0
Структура БД
    #34360572
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelR Улицы - это 98% справочник имен улиц - типа ул./проспект Иванова/1-го мая и комбинируй на здоровье. да пжалста. токо в одном городе будет
Льва ТОлстого ул
а в другом
Толстого Льва ул
причем будет именно в "поделке китайзкого школьнега", в которую надо будет еще и вписацца 1:1 при подготовке отчетных файлов, не сморя на соображения высокомудрого гуеста. (а самое противное - через год этот кладр будет содержать иные написания того же самого адреса, и опять надо буит вписывацца именно в новое написание.
...
Рейтинг: 0 / 0
Структура БД
    #34360702
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621Остальным: нафига, объясните, пожалуйста, использовать в свой работе чью-то говенную поделку (я имею в виду КЛАДР) с абсолютно идиотской структурой данных только потому, что она есть? Ну тупость же невероятная: добровольно тащить в свою базу данных кусок дерьма, спроектированный пьяным китайским школьником, плюс все ошибки блондинок-операторов.

Эту реплику вы сможете высказать тогда, когда разработаете свою поделку и наймете свой штат блондинок-операторов, которые обеспечат актуальное и полное заполнение базы адресов. А пока лучшего по информационной наполненности справочника, чем КЛАДР я не знаю. Если знаете, то дайте ссылочку. И удачность/неудачность структуры данных меня совершенно не интересует - я всегда могу представить их данные в нужном мне виде.
...
Рейтинг: 0 / 0
Структура БД
    #34360782
sysdba22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Зачем городить огород? Чем плох простой иерархический, древовидный справочник административно-территориальных единиц. Как, например, сделано в платформе Гедымин.
...
Рейтинг: 0 / 0
Структура БД
    #34361910
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Если вы уважаемый мальтшик

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

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

Да я, дружище, имею неудовольствие регулярно читать их сообщения на sql.ru; тут и понимать нечего, все предельно прозрачно.

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

Автору вопроса: всегда критически относитесь к уже существующим источникам данных. Шансы наткнуться на хорошо спроектированную структуру данных внешнего источника исчезающе малы.
...
Рейтинг: 0 / 0
Структура БД
    #34362780
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
4321да пжалста. токо в одном городе будет
Льва ТОлстого ул
а в другом
Толстого Льва ул
причем будет именно в "поделке китайзкого школьнега", в которую надо будет еще и вписацца 1:1 при подготовке отчетных файлов, не сморя на соображения высокомудрого гуеста. (а самое противное - через год этот кладр будет содержать иные написания того же самого адреса, и опять надо буит вписывацца именно в новое написание.
:)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
[name], count(*) n , count(distinct [socr])
А.Толстого	9	2
Алексея Толстого	6	2
им Толстого	1	1
Л.Н.Толстого	4	1
Л.Толстого	165	4
Л.Толстого 1-й	1	1
Л.Толстого 2-й	1	1
Льва Толстого	263	5
Льва Толстого 1-й	4	2
Льва Толстого 2-й	4	2
Льва Толстого 3-й	2	1
Массив 1/1 по ул Толстого	1	1
Толстого 	589	5
Толстого (Кадышево)	1	1
Толстого 1-й	5	3
Толстого 1-я	1	1
Толстого 2-й	5	3
Толстого 3-й	3	2
Толстого 4-й	1	1
...
Рейтинг: 0 / 0
Структура БД
    #34362813
dimichis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
guest_20040621> Если вы уважаемый мальтшик
Автору вопроса: всегда критически относитесь к уже существующим источникам данных. Шансы наткнуться на хорошо спроектированную структуру данных внешнего источника исчезающе малы.

Какой бы была у Вас структура относительно таблицы "Адреса"

Связал как многие советовали Тип_Населенного пункта с таблицей Населенные пункты, Тип_Области с таблицей Обласи, Тип_Улицы с таблицей Улицы. Есть у каго еще какие варианты желательно схемотично. Давно Интересовал вопрос по Адресам и хотелось бы раз и навсегда разобраться с ним.
...
Рейтинг: 0 / 0
Структура БД
    #34362897
Фотография Rin@t
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 dimichis: покажите народу скорректированную схему.
...
Рейтинг: 0 / 0
Структура БД
    #34362961
Фотография shelsoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621:
-"Словари цитируйте девочкам с Тверской."
-"Нафига, объясните, пожалуйста, использовать в свой работе чью-то говенную поделку"
-"Кусок дерьма, спроектированный пьяным китайским школьником"
-"Дерьмом не занимался и вряд ли когда-то буду"

shelsoft:
"Если вы уважаемый мальтшик ..."

guest_20040621:
-"не стоит так разговаривать с незнакомыми людьми".

Абыдылся да ?
Да, побрызгаю слюной пальчики растопырю :-) - если приспичет не звоните условно скажем по "911", а то вдруг "Конфуз может приключиться" - вляпаетесь как раз в "межведомственную информационную систему"
________________________________________________________________________________________

В действительности есть проблема с классификаторами в том числе и с адресными.
"через год этот кладр будет содержать иные написания того же самого адреса" да,
практически так и бывает. Кроме этого, кроме КЛАДРа каждый уважающий себя город
:-) имеет свой адресный классификатор в который ежегодно вносятся изменения.
Такие изменения вносятся и в ОКАТО (см. пост выше) и другие общеросийские
классификаторы (нет ничего постоянного).
Для системы, которую представил автор этого поста в принципе можно
использовать и свой справочник. Но ...
1) Откуда брать первичную информацию ?
2) Если это журнал, то как вы будете стыковаться распространителями - или у вас своя сеть ?
3) Как в этом случае возможно отследить все изменения в адресах ?
А при большом тираже ? А по России ?


________________________________________________________________________________________
... Как что достать - вторая эскадрилья. А как самолеты сбивать - первая эскадрилья ...
...
Рейтинг: 0 / 0
Структура БД
    #34363006
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторраз и навсегда разобраться с нимС этим - это с чем?
- печатать адрес в понятном почтальонам разных стран формате,
- привязка к геоинформационной системе,
- группировка по регионам, городам в логистических/статистических целях,
- налоговая отчетность,
- обмен данными со смежными организациями,
- ??
Вряд ли есть универсальный рецепт на все.
...
Рейтинг: 0 / 0
Структура БД
    #34363088
dimichis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Скорректированная схема
...
Рейтинг: 0 / 0
Структура БД
    #34363414
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Скорректированная схема

Давайте разберемся с адресами, остальное пока оставьте. Вот прямо так по порядку и начнем.

Страны - это хорошо. Ваша схема предполагает однозначную административно-территориальную зависимость: страна - область - район - населенный пункт. Т. е. Вы полагаете, что это справедливо для любой страны? Собственных названий административно-территориальных единиц быть не может? Еще одна проблема для этой части схемы: некоторые адреса будут содержать NULL (или предопределенные эквивалентные значения - не суть), что в данном случае плохо (надеюсь, не надо объяснять, почему).

На Вашей схеме страны, области, районы, населенные пункты существуют независимо друг от друга. Нормальный вариант должен предполагать возможность получения административно-территориальной структуры явным образом.
...
Рейтинг: 0 / 0
Структура БД
    #34363543
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelR- печатать адрес в понятном почтальонам разных стран формате,http://www.upu.int/post_code/en/postal_addressing_systems_member_countries.shtml
...
Рейтинг: 0 / 0
Структура БД
    #34363841
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> печатать адрес в понятном почтальонам разных стран формате

...и на понятном почтальонам языке. Вот с основной структурой закончим и сразу добавим мультиязычность.
...
Рейтинг: 0 / 0
Структура БД
    #34363854
dimichis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Получилась такая схема адреса., я правильно понял.
...
Рейтинг: 0 / 0
Структура БД
    #34363902
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimichisПолучилась такая схема адреса., я правильно понял.
в кладре раши есь "области" типа:
"Москва г" и "Питер г"
в них встречаются нас пункты вида скажем "Зеленоград г" без района.
такоже есть и иные города областного подчинения (без районов)

как вы унаследуете такой город в вашей схеме без р-на? введете "пустой" р-н?



ModelR :) не то слово. То, скажем, "мать перематьская", а то с 2007 года - "мать - перематьская". Так и жди "мать - перематьскую" (с пробелами) и т.п.
...
Рейтинг: 0 / 0
Структура БД
    #34364007
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimichisПолучилась такая схема адреса., я правильно понял.

В России
а) Многие города делятся на районы.
б) Многие города не входят ни в какой район, а являются городами так называемого "областного подчинения" (в каждой области таких не менее двух-трех штук).
в) Есть два города (Москва и Питер) федерального подчинения (то есть они даже в область не входят).
г) Есть населенные пункты, являющиеся частью других населенных пунктов (ну например, уже упоминавшися здесь Зеленоград)
д) Существуют адреса вне населенных пунктов вообще. Например, 133 км такого-то шоссе (есть и похуже).

За рубежом все может оказаться еще хуже - у них свои правила формирования адресов.
...
Рейтинг: 0 / 0
Структура БД
    #34364128
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Получилась такая схема адреса

Уже лучше. Посмотрите: у Вас получилась иерархия страна -> область -> район -> населенный пункт. Логично и оформить ее в виде иерархии (страны - оставить как есть, отдельно). Добавить имена территориальных единиц с учетом страны. Добавить маску, регламентирующую допустимые сочетания территориальных единиц с учетом страны. Дополнитеьная группировка (любые территориальные или экстерриториальные образования) - с учетом типов территориальных единиц. Основной плюс: иерархия позволит избежать жесткой структуры адреса.

Кроме того, на Вашем месте я бы отдельно рассматривал физически доступные адреса (условно такие, которые имеют реальные физические координаты) и виртуальные (не имеющие таких координат; например, почтовые ящики).

Остаются индексы, улицы и собственно адресация.
...
Рейтинг: 0 / 0
Структура БД
    #34364605
atv_13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Таблица "Подписчики" не нужна
Зачем в "Физические лица" поле "Мероприятия"? ИМХО ошибка
Выносим из "Физические лица" контактную информацию (типа Домашний_Телефон, Сотовый_Телефон, Mail) в отдельную таблицу "Средства связи" (Физическое_Лицо_Код, Средство_Связи_Код, Значение + возможно надо добавить Адресная_Книга_Код для привязки телефона к адресу и, например, получению кода города для телефона)
В "Адресная книга" из "Адреса" переносим Тип_Квартиры_Код, Квартира, Дополнение_К_Адресу
Соответственно в "Подписки" заменить Адрес_Код на Адресная_Книга_Код и убрать избыточное Подписчик_Код
В итоге "Адреса" - есть ни что иное как своего рода КЛАДР

----
С уважением, Алексей
...
Рейтинг: 0 / 0
Структура БД
    #34364632
dimichis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
[quot guest_20040621]>
Уже лучше. Посмотрите: у Вас получилась иерархия страна -> область -> район -> населенный пункт. Логично и оформить ее в виде иерархии (страны - оставить как есть, отдельно). Добавить имена территориальных единиц с учетом страны. Добавить маску, регламентирующую допустимые сочетания территориальных единиц с учетом страны. Дополнитеьная группировка (любые территориальные или экстерриториальные образования) - с учетом типов территориальных единиц. Основной плюс: иерархия позволит избежать жесткой структуры адреса.
quot]

Всю голову сломал пытаясь понять выше сказанное, как это реализовать в схеме. Суть проблемы понимаю, но как решить никак не пойму.
...
Рейтинг: 0 / 0
Структура БД
    #34364640
atv_13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
И еще ИМХО
Обсуждение опечаток и переименований в КЛАДРе не столь важно для данной схемы, поскольку адреса в оной используются не для сдачи отчетности в ФНС и ПФР с тестированием правильности адресов на соответствие используемым "эталонным" справочникам
В конце-концов, если это для кого-то критично, можно просто периодически проверять/апдейтить на/в соответствие с текущим КЛАДРом

ЗЫ
В "Адресная книга" стоит добавить поле "Произвольный_Адрес", то бишь адрес в произвольном формате
---
С уважением, Алексей
...
Рейтинг: 0 / 0
Структура БД
    #34364684
dimichis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
atv_13
Зачем в "Физические лица" поле "Мероприятия"? ИМХО ошибка

Некий человек т.е. физическое лицо может посетить несколько мероприятий (Конгрес, Симпозиум, Форум итд.) или вы имеете ввиду связать мероприятие с Контрагентами.
...
Рейтинг: 0 / 0
Структура БД
    #34364718
atv_13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dimichisНекий человек т.е. физическое лицо может посетить несколько мероприятийДля указания данного факта у Вас есть "Списки_Мероприятий"
---
С уважением, Алексей
...
Рейтинг: 0 / 0
Структура БД
    #34364798
atv_13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Для Юрлиц обычно имеется контактное лицо (тот же "Директору ООО "Рога и Копыта" :) )
Посему вместо "Контрагенты" уместнее использовать "Физические_Лица", которые связать с "Юридические Лица" таблицей нечто вроде "Работает_В" (Юридическое_Лицо_Код, Физическое_Лицо_Код, Должность + можно добавить Даты_Работы)
В "Подписки" наверно должно быть еще нечто вроде Издание_Код, Период_Подписки, Способ_Доставки
Ну и наверно должно быть что-то насчет оплаты подписки, статуса каждого номера подписного издания и т.п.

----
С уважением, Алексей
...
Рейтинг: 0 / 0
Структура БД
    #34364819
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
atv_13Для Юрлиц обычно имеется контактное лицо...

Посему вместо "Контрагенты" уместнее использовать "Физические_Лица" , которые связать с "Юридические Лица" таблицей нечто вроде "Работает_В" (Юридическое_Лицо_Код, Физическое_Лицо_Код, Должность + можно добавить Даты_Работы)
дате две

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


т.ч. иногда уместнее молчать в трапочку, чем предлагать заведомо гнилые решения.
ничего личного.
...
Рейтинг: 0 / 0
Структура БД
    #34364831
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
заодно повторяю рекомендацию:
1. связь контрагенты - лица сделать 1:1 (что легко делается в аксе, если связываемое поле подчиненной таблицы уникально)
2. т.к. любое лицо у вас -контрагент, то для связи с контрагентами и ключа лиц достаточно одного поля. Т.е. для пк : в контрагенте - суррогат-счетчик, а в лицах - длинное целое (оно же - поле связи).
...
Рейтинг: 0 / 0
Структура БД
    #34365044
atv_13Для Юрлиц обычно имеется

для этого обычно заводят таблицу Employees
...
Рейтинг: 0 / 0
Структура БД
    #34365051
4321заодно повторяю рекомендацию

и это, кстати, далеко не самая удачная и состоятельная из ваших рекомендаций ИМХО

используемая автором структура из трех таблиц

Контрагенты
ФизЛица
ЮрЛица

представляется куда как более подходящей...

кстати в данном случае именно таким образом и реализуется связь один_к_одному, то, что контрагент может быть указан и как физическое лицо и как юридическое можно считать скорее плюсом чем минусом такой организации схемы данных
...
Рейтинг: 0 / 0
Структура БД
    #34365667
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Суть проблемы понимаю, но как решить никак не пойму.

Делайте так, как считаете целесообразным. В данном случае, возможно, и нет необходимости использовать сложную структуру, если база данных активно развиваться не будет.
...
Рейтинг: 0 / 0
Структура БД
    #34365715
atv_13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Да, чой-то я не учел работу в нескольких местах
Как такой вариант "Контрагенты" = (Контрагент_ID, Юридические_Лица_Код, Физические_Лица_Код) ??
...
Рейтинг: 0 / 0
Структура БД
    #34365853
dimichis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
atv_13 dimichisНекий человек т.е. физическое лицо может посетить несколько мероприятийДля указания данного факта у Вас есть "Списки_Мероприятий"
---
С уважением, Алексей

Ой точно забыл удалить это поле(Невнимательность)
...
Рейтинг: 0 / 0
Структура БД
    #34365865
dimichis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
atv_13В "Подписки" наверно должно быть еще нечто вроде Издание_Код, Период_Подписки, Способ_Доставки
Ну и наверно должно быть что-то насчет оплаты подписки, статуса каждого номера подписного издания и т.п.

----
С уважением, Алексей

Пока дальше не развивал схему.Топчусь с адресом.
...
Рейтинг: 0 / 0
Структура БД
    #34365893
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> Суть проблемы понимаю, но как решить никак не пойму.

Чтобы совсем запутать вопрос :)
Если адреса - ТОЛЬКО для почтальонов,
то достаточно 6-7 текстовых полей address_line1,address_line2,... - что подписчик написал, туда и отправим.

Вам нужно четко сформулировать требования к вашей системе.
Например области. По конституции России, страна делится на субъекты федерации. А еще страна делится на территории железных дорог, на экономические районы, климатические зоны, на округа ПВО наконец. Для каких целей (см. выше) нужны в системе деления?

Точка зрения почты :
Index Индекс ОПС в соответствии с действующей системой индексации
OPSName Наименование объекта почтовой связи
OPSType Тип объекта почтовой связи
OPSSubm Индекс вышестоящего по иерархии подчиненности объекта почтовой связи
Region Наименование области, края, республики, в которой находится ОПС
Autonom Наименование автономной области, в которой находится ОПС
Area Наименование района, в котором находится ОПС
City Наименование населенного пункта, в котором находится ОПС
City1 Наименование подчиненного населенного пункта, в котором находится ОПС
ActDate Дата актуализации информации об ОПС
IndexOld Индекс ОПС до ввода действующей системы индексации
...
Рейтинг: 0 / 0
Структура БД
    #34365922
цуекцйуецуе 4321заодно повторяю рекомендацию

и это, кстати, далеко не самая удачная и состоятельная из ваших рекомендаций ИМХО

используемая автором структура из трех таблиц

Контрагенты
ФизЛица
ЮрЛица

представляется куда как более подходящей...

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

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

я же покуда говорил о желательности заменить связи 1-много на связи 1:1. что считать преимуществом, а что нет - вопрос таки к бизнес-задаче, а не к домыслам посторонних.


связь 1:много вполне может быть приемлема, если считать разные инкарнации контрагента всего лишь различными (по времени или иное) его представлениями. Но такое ведение справочников требует и определенных усилий - например с тем, чтобы однозначно выбирать требуемую инкарнацию при составлении того или иного документа (отчета), и т.п.
...
Рейтинг: 0 / 0
Структура БД
    #34366036
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Если адреса - ТОЛЬКО для почтальонов

В России нет монополии на доставку почтовой корреспонденции. Есть и альтернативные подписные каталоги, и альтернативные распространители. Если пользоваться их услугами, они хотят базу подписчиков в их формате (по крайней мере те, с которыми я сталкивался). Ничего запредельного, но выделять, например, типы домовладений (в адресе указывается "строение", а не "дом") они хотят. И понятно, почему: у них есть собственная база данных, к которой есть стандартные тулзы импорта/экспорта, которые они не будут переписывать для каждого клиента. К чему, собственно, сказанное: насколько болезненным окажется упрощение модели - сложно сказать. Ну, и о достоверности пара слов. На самом деле "ул. Бумажная" и "Бумажная ул." - суть разные названия. Одно из них соответствует градостроительному плану, другое - нет.

Вообще говоря, в хорошей структуре данных количество информации должно быть больше, чем в каждом из отдельно взятых внешних источников.
...
Рейтинг: 0 / 0
Структура БД
    #34366141
dimichis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
guest_20040621адре
Уже лучше. Посмотрите: у Вас получилась иерархия страна -> область -> район -> населенный пункт. Логично и оформить ее в виде иерархии (страны - оставить как есть, отдельно). Добавить имена территориальных единиц с учетом страны. Добавить маску, регламентирующую допустимые сочетания территориальных единиц с учетом страны. Дополнитеьная группировка (любые территориальные или экстерриториальные образования) - с учетом типов территориальных единиц.
Остаются индексы, улицы и собственно адресация.
Уважаемы guest_20040621 не могли бы вы описать связи между таблицами Страны, Области, Районы, Населенные_Пункты. Ну никак не пойму как их так хитро связать с учетом таких требований
автора) Многие города делятся на районы.
б) Многие города не входят ни в какой район, а являются городами так называемого "областного подчинения" (в каждой области таких не менее двух-трех штук).
в) Есть два города (Москва и Питер) федерального подчинения (то есть они даже в область не входят).
г) Есть населенные пункты, являющиеся частью других населенных пунктов (ну например, уже упоминавшися здесь Зеленоград)
д) Существуют адреса вне населенных пунктов вообще. Например, 133 км такого-то шоссе (есть и похуже).
...
Рейтинг: 0 / 0
Структура БД
    #34366149
йо-хо-хо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
guest_20040621Вообще говоря, в хорошей структуре данных количество информации должно быть больше, чем в каждом из отдельно взятых внешних источников.

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

в общем хватит банальностей

по здравом размышлении, я советовал бы бойтись КЛАДР-ом, по крайней мере на первых шагал (допустим на первом релизе)

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

сосредоточтесь на решении основных задач, потом уже переходите к второстепенным

(субуго ИМХО)

типо - КЛАДР в access:
...
Рейтинг: 0 / 0
Структура БД
    #34366218
dimichisНу никак не пойму как их так хитро связать с учетом таких требований

ИМХО вы тратите время впустую - такой четкой и однозначной структуры не существует, а если бы и существовала - вы не можете гарантировать, что она не изменится уже завтра.

и потом... вы же не решаете задучу административно-территориального деления Субъектов РФ и наследуемой соподчиненности топонимических объектов на территории России - ваша прикладная область этого

1 не требует
2 не контролирует

т.е. вы пытаетесь решить задачу вообще не относящуюся к разрабатываемому вами приложению...

как уже советовали ранее - можно ограничиться "адресом доставки"

Country
Region
City
Area
AddressLine1
AddressLine2

или как уже советовали ранее можно использовать КЛАДР - его со всеми адресами можно либо купить либо выкачать в сети (сюда, как атачмент, боюсь не влезет)
...
Рейтинг: 0 / 0
Структура БД
    #34366229
dimichis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
типо таки да
или как уже советовали ранее можно использовать КЛАДР - его со всеми адресами можно либо купить либо выкачать в сети (сюда, как атачмент, боюсь не влезет)
Плиз кинь на мыло Access вариант кладра dimichis@mail.ru
...
Рейтинг: 0 / 0
Структура БД
    #34366288
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> а) Многие города делятся на районы.

Это административное деление. Муниципального уровня.

> б) Многие города не входят ни в какой район, а являются городами так называемого
> "областного подчинения" (в каждой области таких не менее двух-трех штук).

Это тоже административное деление. Областного уровня.

> в) Есть два города (Москва и Питер) федерального подчинения (то есть они даже
> в область не входят).

И это административное деление. Федерального уровня.

> г) Есть населенные пункты, являющиеся частью других населенных пунктов
> (ну например, уже упоминавшися здесь Зеленоград)

И это административное деление. Муниципального(?) уровня.

> д) Существуют адреса вне населенных пунктов вообще.
> Например, 133 км такого-то шоссе (есть и похуже).

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


> избыточная информация не плюс

Я так не считаю.

> идеальных источников информации не существует

99,9% баз данных - не источники, а коллекторы. И не информации, а данных. Из данных информацию еще нужно извлечь.

> чем больше данных тем больше ошибок и тем труднее их найти

Для уменьшения ошибок и придуманы реляционные СУБД, стандарты и приемы проектирования.
...
Рейтинг: 0 / 0
Структура БД
    #34366509
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimichisвариант кладра dimichis@mail.ru
взять
http://www.gnivc.ru/downloads/kladr.aspx
и импортировать таблицы в акс.
...
Рейтинг: 0 / 0
Структура БД
    #34366773
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> а) Многие города делятся на районы.
Это административное деление. Муниципального уровня.
и т.п.


Это не только административное деление. Иногда это существенная часть адреса, позволяющая однозначно идентифицировать объект. Точно так же как области и сельские районы.
Но от адреса требуется не просто однозначная идентификация строительных сооружений. В большинстве случаев есть необходимость объединения адресов в группы "близколежащих". И в этом плане выделение группы объектов, находящихся в одном административном районе очень полезно.
...
Рейтинг: 0 / 0
Структура БД
    #34367304
Bogdanov AndreyНо от адреса требуется не просто.

от почтового адреса никогда и не требовалось "однозначной идентификации строительных сооружений" - такое может потребоваться разве что при выписке наряда-задания на снос объекта - чтобы лишнего не наломали ... :)

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

а уж про мифическое "большинство случаев" и говорить не хочется - расхожий аргумент из разряда спекулятивных
...
Рейтинг: 0 / 0
65 сообщений из 65, показаны все 3 страниц
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Структура БД
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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