|
|
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
Проектирую структуру БД Подписок на различные журналы. С некоторой частью помогли разобраться в саседнем форуме "Access". 1) Интересует таблица "Списки_Мероприятий" верный ли я подход использовал для реализации идеи что физическое лицо может посетить несколько мероприятий (Конгресс, Форум, Симпозиум итд.)? 2) Интересует таблица "Адреса". Что-то много справочников получается у этой таблицы или как-то можно подругому сгрупировать поля? 3)Может есть какие нибудь еще недочеты, мнения, критика. Взаранее спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 17:13 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
Наверно слишком мелко получилось вот покрупней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 17:22 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
Бегло просмотрев.... Ума не приложу, зачем нужны справочники типов (городов, областей, улиц). Что это такое? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 17:22 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
Есть тип города (Город, деревня, село, послелок итд). Есть тип области (Область, край , Автономный округ итд) разьве не надо их выносить в справочник чтобы подставлять их а не забивать вручную каждый раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 17:27 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
dimichisЕсть тип города (Город, деревня, село, послелок итд). Есть тип области (Область, край , Автономный округ итд) разьве не надо их выносить в справочник чтобы подставлять их а не забивать вручную каждый раз.гм. согласно кладру могет быть нас.пункт приписан к городу. : (..р-н, мухосранск г, пупкино п (или мкр), чесалова ул...)т.ч. видимо надоть ...городнас пунктулица с другой - т.к. у вас есть справочник городов и улитц, то повторение полей типов и в справочнике (улиц/нас пунктов) и в Адресе - избыточно. Что, кстати сказать, чревато. Т.ч. предлагаю в "адресе" поля типов убить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 17:37 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
dimichisЕсть тип города (Город, деревня, село, послелок итд). Смесь бульдога с носорогом :-). Imho вернее использовать термин "тип населённого пункта". И в адресе (Адреса) их указывать не надо - очевидная избыточность. Тип населённого пункта привязывается к населённому пункту. dimichisЕсть тип области (Область, край , Автономный округ итд) разьве не надо их выносить в справочник чтобы подставлять их а не забивать вручную каждый раз. Выносить надо. Также как понимать, что это агрегаты: насёленные пункты (Город, деревня, село, поселок) являются принадлежностью областей, краёв, округов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 17:39 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
что еще не понятно: у вас один контрагент имеет множественное представительство и в ЮрЛицах и в ФизЛицах. Так и должно быть? или вы просто не умеете задавать связь 1:1? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 17:43 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
4321что еще не понятно: у вас один контрагент имеет множественное представительство и в ЮрЛицах и в ФизЛицах. Так и должно быть? или вы просто не умеете задавать связь 1:1? Контрагент может быть 1)Юредическим лицом рабочий адрес, 2)Физическим лицом домашний адрес, 3)Физическим лицом на рабочий адрес юридического лица (т.е. где он работает) 4) И вообще просто человек, почтальен, курьер итд. Именно такой вариант мне посаветовали на соседнем форуме "Access". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 17:52 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
Информацию о банках необходимо выделить в отдельную таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 17:52 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
Rin@tИнформацию о банках необходимо выделить в отдельную таблицу. Спасибо. Предпологал это делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 17:59 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
Често говоря так и непонял что делать с типами. Как удалить непойму. В поле город будет введено (Москва, Пушкино без всяких г.Москва, п.Пушкино), поэтому и делаю тип города, области, улици итд. Можно поподробнее с примерчиком или схемкой как данные будут храниться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 18:19 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
По поводу адресов - есть такая штука "ОКАТО" - Общеросийский классификатор админ.-терр. деления - есть такая штука "ОКСМ" - Общеросийский классификатор стран мира - есть такая штука "Адресная система" - енто в налоговую МНС посмотрите - появятся трезвые мысли по поводу адресов ... _________________________________________________________________________________ ... Как что достать - вторая эскадрилья. А как самолеты сбивать - первая эскадрилья ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 18:41 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
dimichisЧесто говоря так и непонял что делать с типами. Как удалить непойму. В поле город будет введено (Москва, Пушкино без всяких г.Москва, п.Пушкино), поэтому и делаю тип города, области, улици итд. Можно поподробнее с примерчиком или схемкой как данные будут храниться. Таблица "Города" должна быть связана с таблицей "Типы городов" (настоятельно рекомендую заменить название таблицы "Города" на "Населённые пункты", "Типы городов" на "Типы населённых пунктов". Названия "Города" и "Типы городов" применительно к вашей БД выглядят нелепо). Аналогично устанавливаются связи и для других пар таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2007, 09:34 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
> 1) Интересует таблица "Списки_Мероприятий" верный ли я подход использовал > для реализации идеи что физическое лицо может посетить несколько мероприятий При условии, что они не проходят в одно и то же время. > 2) Интересует таблица "Адреса". Что-то много справочников получается у этой таблицы > или как-то можно подругому сгрупировать поля? Здесь все плохо. Нормализуйте основную таблицу. Используйте отдельно административное и отдельно территориальное деление. Избавьтесь от лишних типов. > 3)Может есть какие нибудь еще недочеты, мнения, критика. Никакая схема. Поработаете с ней - поймете, почему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2007, 10:20 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
dimichisЧесто говоря так и непонял что делать с типами. Как удалить непойму. В поле город будет введено (Москва, Пушкино без всяких г.Москва, п.Пушкино), поэтому и делаю тип города, области, улици итд. Можно поподробнее с примерчиком или схемкой как данные будут храниться. Сейчас во многих организациях используется так называемый общероссийский классификатор адресов (КЛАДР). Либо напрямую, либо данные из него загружаются. Этот классификатор содержит официальный способ адресации. Очень рекомендую ознакомится с его устройством (в любом поисковике набираете "КЛАДР"), так как если ваша разработка будет практически использоваться то вероятность, что связываться с классификатором потребуется достаточно высока. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2007, 10:30 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
> Этот классификатор содержит официальный способ адресации. Да ну? В Российской Федерации служебные документы ФНС уже имеют силу законов? Чуши не пишите, пожалуйста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2007, 10:44 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Этот классификатор содержит официальный способ адресации. Да ну? В Российской Федерации служебные документы ФНС уже имеют силу законов? Чуши не пишите, пожалуйста. А где вы в моем посте слово "закон" увидели? На всякий случай (если у вас трудности с языком) выдержка: толковый словарь русского языкаОФИЦИАЛЬНЫЙ прил. - Правительственный или должностной. // Исходящий от правительственных органов или должностных лиц. Вы хотите сказать, что ФНС (а также пенсионный фонд, например) не является правительственным органом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2007, 11:13 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
2 guest_20040621 & Bogdanov Andrey: да ладно вам спорить, отклонившись от темы топика. Схема, предложенная для обсуждения, - тихий ужас. "Нормализуйте основную таблицу" - очень хорошее предложение. Знает ли автор об этом? В сети немало материалов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2007, 11:39 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
dimichis 4321что еще не понятно: у вас один контрагент имеет множественное представительство и в ЮрЛицах и в ФизЛицах. Так и должно быть? или вы просто не умеете задавать связь 1:1? Контрагент может быть 1)Юредическим лицом рабочий адрес, 2)Физическим лицом домашний адрес, 3)Физическим лицом на рабочий адрес юридического лица (т.е. где он работает) 4) И вообще просто человек, почтальен, курьер итд. Именно такой вариант мне посаветовали на соседнем форуме "Access".йопта. Вы читаете, что вам пишут? Вы хотя бы читаете то, что сами цитируете? Итак вы пишете: контрагент у вас может быть. при этом он может быть лицом. когда он сможет быть лицами, а не лицом, тогда и будете устанавливать связь 1:допупа, пока же вас устроит связь 1:1 (как ее установить в аксе - спросите в форуме акса). а то, что контрагент могет иметь массу адресов, описывается не связями контрагент-лицо, а связями контрагент-...-адрес (у вас связь опосредована еще и некой книгой) ================================================================ касательно типа города в адресе: скажем есть 2 адреса, в которые входит некий (один и тот же) город мухосранск. Причем в первый адрес он входит как "город", а в другой - как "поселок городского типа". Это ваша схема позволяет. Так правильно ли это? Или свойство мухосранска быть деревней это таки св-во мухосранска, а не св-во некоего адреса, в который мухосранску не повезло попасть? (то же и по прочим вхождениям "типов" в адрес, а не в объект, тип которого они задают) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2007, 12:08 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
4321т.к. у вас есть справочник городов и улитц, то повторение полей типов и в справочнике (улиц/нас пунктов) и в Адресе - избыточно. Что, кстати сказать, чревато. Т.ч. предлагаю в "адресе" поля типов убить.Не, города и улицы устроены у автора по-разному. Улицы - это 98% справочник имен улиц - типа ул./проспект Иванова/1-го мая и комбинируй на здоровье. Города содержат индивидуализирующие атрибуты и видимо это истинно города а не имена. так что тип города уместен в городе, а не адресе. В КЛАДР типы присутсвуют отдельным полем и таблицей, причем по уровням. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2007, 12:50 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
dimichisКонтрагент может быть 1)Юредическим лицом рабочий адрес, 2)Физическим лицом домашний адрес, 3)Физическим лицом на рабочий адрес юридического лица (т.е. где он работает) 4) И вообще просто человек, почтальен, курьер итд. Именно такой вариант мне посаветовали на соседнем форуме "Access".Тогда проще связать их прямо по первичным ключам КонтрнагентИД==ЮрлицоИД, КонтрнагентИД==ЮрлицоИД. КонтрагентКод в Юрлицах и Физлицах лишний. Или это специфика Access? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2007, 13:04 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
Bogdanov Andrey, понял, вычеркиваю. Словари цитируйте девочкам с Тверской. Остальным: нафига, объясните, пожалуйста, использовать в свой работе чью-то говенную поделку (я имею в виду КЛАДР) с абсолютно идиотской структурой данных только потому, что она есть? Ну тупость же невероятная: добровольно тащить в свою базу данных кусок дерьма, спроектированный пьяным китайским школьником, плюс все ошибки блондинок-операторов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2007, 13:16 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
"Остальным: нафига, объясните, пожалуйста, использовать в свой работе чью-то говенную поделку" Если вы уважаемый мальтшик, когда-нибудь (надеюсь, что не доживу ;-) ) займетесь разработкой межведомственных информационных систем (или хотя бы будете решать вопрос взаимодействия данных хотя бы двух систем) построенных на основе собственных классификаторов без использования общих "идиотских структур данных" то поймете кук размножаются "пьяные китайские школьники" плюс все "блондиноки-операторовы". _________________________________________________________________________________ ... Как что достать - вторая эскадрилья. А как самолеты сбивать - первая эскадрилья ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2007, 13:52 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
ModelR Улицы - это 98% справочник имен улиц - типа ул./проспект Иванова/1-го мая и комбинируй на здоровье. да пжалста. токо в одном городе будет Льва ТОлстого ул а в другом Толстого Льва ул причем будет именно в "поделке китайзкого школьнега", в которую надо будет еще и вписацца 1:1 при подготовке отчетных файлов, не сморя на соображения высокомудрого гуеста. (а самое противное - через год этот кладр будет содержать иные написания того же самого адреса, и опять надо буит вписывацца именно в новое написание. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2007, 13:53 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621Остальным: нафига, объясните, пожалуйста, использовать в свой работе чью-то говенную поделку (я имею в виду КЛАДР) с абсолютно идиотской структурой данных только потому, что она есть? Ну тупость же невероятная: добровольно тащить в свою базу данных кусок дерьма, спроектированный пьяным китайским школьником, плюс все ошибки блондинок-операторов. Эту реплику вы сможете высказать тогда, когда разработаете свою поделку и наймете свой штат блондинок-операторов, которые обеспечат актуальное и полное заполнение базы адресов. А пока лучшего по информационной наполненности справочника, чем КЛАДР я не знаю. Если знаете, то дайте ссылочку. И удачность/неудачность структуры данных меня совершенно не интересует - я всегда могу представить их данные в нужном мне виде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2007, 14:18 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
Зачем городить огород? Чем плох простой иерархический, древовидный справочник административно-территориальных единиц. Как, например, сделано в платформе Гедымин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2007, 14:42 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
> Если вы уважаемый мальтшик Дружище, Вы действительно хотите услышать все, что я по этому поводу думаю? Может, ну его нафиг? - обидетесь, расстроетесь, будете топорщить пальчики и брызгать слюной. Просто поверьте: не стоит так разговаривать с незнакомыми людьми. Конфуз может приключиться. > то поймете кук размножаются "пьяные китайские школьники" плюс все "блондиноки-операторовы". Да я, дружище, имею неудовольствие регулярно читать их сообщения на sql.ru; тут и понимать нечего, все предельно прозрачно. По поводу "межведомственных информационных систем" разочарую: дерьмом не занимался и вряд ли когда-то буду. В основном потому, что тупую работу я делаю очень задорого, так что работодателю дешевле нанять десяток таких, как Вы. Доходчиво? Автору вопроса: всегда критически относитесь к уже существующим источникам данных. Шансы наткнуться на хорошо спроектированную структуру данных внешнего источника исчезающе малы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2007, 21:38 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
4321да пжалста. токо в одном городе будет Льва ТОлстого ул а в другом Толстого Льва ул причем будет именно в "поделке китайзкого школьнега", в которую надо будет еще и вписацца 1:1 при подготовке отчетных файлов, не сморя на соображения высокомудрого гуеста. (а самое противное - через год этот кладр будет содержать иные написания того же самого адреса, и опять надо буит вписывацца именно в новое написание. :) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 10:57 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Если вы уважаемый мальтшик Автору вопроса: всегда критически относитесь к уже существующим источникам данных. Шансы наткнуться на хорошо спроектированную структуру данных внешнего источника исчезающе малы. Какой бы была у Вас структура относительно таблицы "Адреса" Связал как многие советовали Тип_Населенного пункта с таблицей Населенные пункты, Тип_Области с таблицей Обласи, Тип_Улицы с таблицей Улицы. Есть у каго еще какие варианты желательно схемотично. Давно Интересовал вопрос по Адресам и хотелось бы раз и навсегда разобраться с ним. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 11:05 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
2 dimichis: покажите народу скорректированную схему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 11:22 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621: -"Словари цитируйте девочкам с Тверской." -"Нафига, объясните, пожалуйста, использовать в свой работе чью-то говенную поделку" -"Кусок дерьма, спроектированный пьяным китайским школьником" -"Дерьмом не занимался и вряд ли когда-то буду" shelsoft: "Если вы уважаемый мальтшик ..." guest_20040621: -"не стоит так разговаривать с незнакомыми людьми". Абыдылся да ? Да, побрызгаю слюной пальчики растопырю :-) - если приспичет не звоните условно скажем по "911", а то вдруг "Конфуз может приключиться" - вляпаетесь как раз в "межведомственную информационную систему" ________________________________________________________________________________________ В действительности есть проблема с классификаторами в том числе и с адресными. "через год этот кладр будет содержать иные написания того же самого адреса" да, практически так и бывает. Кроме этого, кроме КЛАДРа каждый уважающий себя город :-) имеет свой адресный классификатор в который ежегодно вносятся изменения. Такие изменения вносятся и в ОКАТО (см. пост выше) и другие общеросийские классификаторы (нет ничего постоянного). Для системы, которую представил автор этого поста в принципе можно использовать и свой справочник. Но ... 1) Откуда брать первичную информацию ? 2) Если это журнал, то как вы будете стыковаться распространителями - или у вас своя сеть ? 3) Как в этом случае возможно отследить все изменения в адресах ? А при большом тираже ? А по России ? ________________________________________________________________________________________ ... Как что достать - вторая эскадрилья. А как самолеты сбивать - первая эскадрилья ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 11:37 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
авторраз и навсегда разобраться с нимС этим - это с чем? - печатать адрес в понятном почтальонам разных стран формате, - привязка к геоинформационной системе, - группировка по регионам, городам в логистических/статистических целях, - налоговая отчетность, - обмен данными со смежными организациями, - ?? Вряд ли есть универсальный рецепт на все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 11:47 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
Скорректированная схема ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 12:06 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
> Скорректированная схема Давайте разберемся с адресами, остальное пока оставьте. Вот прямо так по порядку и начнем. Страны - это хорошо. Ваша схема предполагает однозначную административно-территориальную зависимость: страна - область - район - населенный пункт. Т. е. Вы полагаете, что это справедливо для любой страны? Собственных названий административно-территориальных единиц быть не может? Еще одна проблема для этой части схемы: некоторые адреса будут содержать NULL (или предопределенные эквивалентные значения - не суть), что в данном случае плохо (надеюсь, не надо объяснять, почему). На Вашей схеме страны, области, районы, населенные пункты существуют независимо друг от друга. Нормальный вариант должен предполагать возможность получения административно-территориальной структуры явным образом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 13:15 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
ModelR- печатать адрес в понятном почтальонам разных стран формате,http://www.upu.int/post_code/en/postal_addressing_systems_member_countries.shtml ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 13:50 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
> печатать адрес в понятном почтальонам разных стран формате ...и на понятном почтальонам языке. Вот с основной структурой закончим и сразу добавим мультиязычность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 14:54 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
Получилась такая схема адреса., я правильно понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 14:57 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
dimichisПолучилась такая схема адреса., я правильно понял. в кладре раши есь "области" типа: "Москва г" и "Питер г" в них встречаются нас пункты вида скажем "Зеленоград г" без района. такоже есть и иные города областного подчинения (без районов) как вы унаследуете такой город в вашей схеме без р-на? введете "пустой" р-н? ModelR :) не то слово. То, скажем, "мать перематьская", а то с 2007 года - "мать - перематьская". Так и жди "мать - перематьскую" (с пробелами) и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 15:10 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
dimichisПолучилась такая схема адреса., я правильно понял. В России а) Многие города делятся на районы. б) Многие города не входят ни в какой район, а являются городами так называемого "областного подчинения" (в каждой области таких не менее двух-трех штук). в) Есть два города (Москва и Питер) федерального подчинения (то есть они даже в область не входят). г) Есть населенные пункты, являющиеся частью других населенных пунктов (ну например, уже упоминавшися здесь Зеленоград) д) Существуют адреса вне населенных пунктов вообще. Например, 133 км такого-то шоссе (есть и похуже). За рубежом все может оказаться еще хуже - у них свои правила формирования адресов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 15:31 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
> Получилась такая схема адреса Уже лучше. Посмотрите: у Вас получилась иерархия страна -> область -> район -> населенный пункт. Логично и оформить ее в виде иерархии (страны - оставить как есть, отдельно). Добавить имена территориальных единиц с учетом страны. Добавить маску, регламентирующую допустимые сочетания территориальных единиц с учетом страны. Дополнитеьная группировка (любые территориальные или экстерриториальные образования) - с учетом типов территориальных единиц. Основной плюс: иерархия позволит избежать жесткой структуры адреса. Кроме того, на Вашем месте я бы отдельно рассматривал физически доступные адреса (условно такие, которые имеют реальные физические координаты) и виртуальные (не имеющие таких координат; например, почтовые ящики). Остаются индексы, улицы и собственно адресация. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 15:55 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
Таблица "Подписчики" не нужна Зачем в "Физические лица" поле "Мероприятия"? ИМХО ошибка Выносим из "Физические лица" контактную информацию (типа Домашний_Телефон, Сотовый_Телефон, Mail) в отдельную таблицу "Средства связи" (Физическое_Лицо_Код, Средство_Связи_Код, Значение + возможно надо добавить Адресная_Книга_Код для привязки телефона к адресу и, например, получению кода города для телефона) В "Адресная книга" из "Адреса" переносим Тип_Квартиры_Код, Квартира, Дополнение_К_Адресу Соответственно в "Подписки" заменить Адрес_Код на Адресная_Книга_Код и убрать избыточное Подписчик_Код В итоге "Адреса" - есть ни что иное как своего рода КЛАДР ---- С уважением, Алексей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 17:45 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
[quot guest_20040621]> Уже лучше. Посмотрите: у Вас получилась иерархия страна -> область -> район -> населенный пункт. Логично и оформить ее в виде иерархии (страны - оставить как есть, отдельно). Добавить имена территориальных единиц с учетом страны. Добавить маску, регламентирующую допустимые сочетания территориальных единиц с учетом страны. Дополнитеьная группировка (любые территориальные или экстерриториальные образования) - с учетом типов территориальных единиц. Основной плюс: иерархия позволит избежать жесткой структуры адреса. quot] Всю голову сломал пытаясь понять выше сказанное, как это реализовать в схеме. Суть проблемы понимаю, но как решить никак не пойму. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 17:53 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
И еще ИМХО Обсуждение опечаток и переименований в КЛАДРе не столь важно для данной схемы, поскольку адреса в оной используются не для сдачи отчетности в ФНС и ПФР с тестированием правильности адресов на соответствие используемым "эталонным" справочникам В конце-концов, если это для кого-то критично, можно просто периодически проверять/апдейтить на/в соответствие с текущим КЛАДРом ЗЫ В "Адресная книга" стоит добавить поле "Произвольный_Адрес", то бишь адрес в произвольном формате --- С уважением, Алексей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 17:56 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
atv_13 Зачем в "Физические лица" поле "Мероприятия"? ИМХО ошибка Некий человек т.е. физическое лицо может посетить несколько мероприятий (Конгрес, Симпозиум, Форум итд.) или вы имеете ввиду связать мероприятие с Контрагентами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 18:09 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
dimichisНекий человек т.е. физическое лицо может посетить несколько мероприятийДля указания данного факта у Вас есть "Списки_Мероприятий" --- С уважением, Алексей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 18:24 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
Для Юрлиц обычно имеется контактное лицо (тот же "Директору ООО "Рога и Копыта" :) ) Посему вместо "Контрагенты" уместнее использовать "Физические_Лица", которые связать с "Юридические Лица" таблицей нечто вроде "Работает_В" (Юридическое_Лицо_Код, Физическое_Лицо_Код, Должность + можно добавить Даты_Работы) В "Подписки" наверно должно быть еще нечто вроде Издание_Код, Период_Подписки, Способ_Доставки Ну и наверно должно быть что-то насчет оплаты подписки, статуса каждого номера подписного издания и т.п. ---- С уважением, Алексей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 18:56 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
atv_13Для Юрлиц обычно имеется контактное лицо... Посему вместо "Контрагенты" уместнее использовать "Физические_Лица" , которые связать с "Юридические Лица" таблицей нечто вроде "Работает_В" (Юридическое_Лицо_Код, Физическое_Лицо_Код, Должность + можно добавить Даты_Работы) дате две я худею, дорогая редакция. физ лица имеют обыкновения увольняца, работать в нескольких местах и т.п. теперь представим, что мероприятие проводицо для компании Х, а ее представитель - еще и директор пары-тройки других компаний. И что? т.ч. иногда уместнее молчать в трапочку, чем предлагать заведомо гнилые решения. ничего личного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 19:05 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
заодно повторяю рекомендацию: 1. связь контрагенты - лица сделать 1:1 (что легко делается в аксе, если связываемое поле подчиненной таблицы уникально) 2. т.к. любое лицо у вас -контрагент, то для связи с контрагентами и ключа лиц достаточно одного поля. Т.е. для пк : в контрагенте - суррогат-счетчик, а в лицах - длинное целое (оно же - поле связи). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 19:10 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
atv_13Для Юрлиц обычно имеется для этого обычно заводят таблицу Employees ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 21:21 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
4321заодно повторяю рекомендацию и это, кстати, далеко не самая удачная и состоятельная из ваших рекомендаций ИМХО используемая автором структура из трех таблиц Контрагенты ФизЛица ЮрЛица представляется куда как более подходящей... кстати в данном случае именно таким образом и реализуется связь один_к_одному, то, что контрагент может быть указан и как физическое лицо и как юридическое можно считать скорее плюсом чем минусом такой организации схемы данных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 21:27 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
> Суть проблемы понимаю, но как решить никак не пойму. Делайте так, как считаете целесообразным. В данном случае, возможно, и нет необходимости использовать сложную структуру, если база данных активно развиваться не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 09:54 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
Да, чой-то я не учел работу в нескольких местах Как такой вариант "Контрагенты" = (Контрагент_ID, Юридические_Лица_Код, Физические_Лица_Код) ?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 10:12 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
atv_13 dimichisНекий человек т.е. физическое лицо может посетить несколько мероприятийДля указания данного факта у Вас есть "Списки_Мероприятий" --- С уважением, Алексей Ой точно забыл удалить это поле(Невнимательность) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 10:43 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
atv_13В "Подписки" наверно должно быть еще нечто вроде Издание_Код, Период_Подписки, Способ_Доставки Ну и наверно должно быть что-то насчет оплаты подписки, статуса каждого номера подписного издания и т.п. ---- С уважением, Алексей Пока дальше не развивал схему.Топчусь с адресом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 10:46 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
> Суть проблемы понимаю, но как решить никак не пойму. Чтобы совсем запутать вопрос :) Если адреса - ТОЛЬКО для почтальонов, то достаточно 6-7 текстовых полей address_line1,address_line2,... - что подписчик написал, туда и отправим. Вам нужно четко сформулировать требования к вашей системе. Например области. По конституции России, страна делится на субъекты федерации. А еще страна делится на территории железных дорог, на экономические районы, климатические зоны, на округа ПВО наконец. Для каких целей (см. выше) нужны в системе деления? Точка зрения почты : Index Индекс ОПС в соответствии с действующей системой индексации OPSName Наименование объекта почтовой связи OPSType Тип объекта почтовой связи OPSSubm Индекс вышестоящего по иерархии подчиненности объекта почтовой связи Region Наименование области, края, республики, в которой находится ОПС Autonom Наименование автономной области, в которой находится ОПС Area Наименование района, в котором находится ОПС City Наименование населенного пункта, в котором находится ОПС City1 Наименование подчиненного населенного пункта, в котором находится ОПС ActDate Дата актуализации информации об ОПС IndexOld Индекс ОПС до ввода действующей системы индексации ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 10:51 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
цуекцйуецуе 4321заодно повторяю рекомендацию и это, кстати, далеко не самая удачная и состоятельная из ваших рекомендаций ИМХО используемая автором структура из трех таблиц Контрагенты ФизЛица ЮрЛица представляется куда как более подходящей... кстати в данном случае именно таким образом и реализуется связь один_к_одному, то, что контрагент может быть указан и как физическое лицо и как юридическое можно считать скорее плюсом чем минусом такой организации схемы данныхесли вы найдете в моей рекомендации посыл об отказе от трех таблиц - флаг вам в руки и .... пока же позвольте считать вас пустобрехом хотя я видел и реализацию всех контрагентов в одной табличке, и нахожу ее вполне жизнеспособной - не являяс нулло-ненавистнегом. но тем не менее нигде выше не рекомендовал я же покуда говорил о желательности заменить связи 1-много на связи 1:1. что считать преимуществом, а что нет - вопрос таки к бизнес-задаче, а не к домыслам посторонних. связь 1:много вполне может быть приемлема, если считать разные инкарнации контрагента всего лишь различными (по времени или иное) его представлениями. Но такое ведение справочников требует и определенных усилий - например с тем, чтобы однозначно выбирать требуемую инкарнацию при составлении того или иного документа (отчета), и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 10:56 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
> Если адреса - ТОЛЬКО для почтальонов В России нет монополии на доставку почтовой корреспонденции. Есть и альтернативные подписные каталоги, и альтернативные распространители. Если пользоваться их услугами, они хотят базу подписчиков в их формате (по крайней мере те, с которыми я сталкивался). Ничего запредельного, но выделять, например, типы домовладений (в адресе указывается "строение", а не "дом") они хотят. И понятно, почему: у них есть собственная база данных, к которой есть стандартные тулзы импорта/экспорта, которые они не будут переписывать для каждого клиента. К чему, собственно, сказанное: насколько болезненным окажется упрощение модели - сложно сказать. Ну, и о достоверности пара слов. На самом деле "ул. Бумажная" и "Бумажная ул." - суть разные названия. Одно из них соответствует градостроительному плану, другое - нет. Вообще говоря, в хорошей структуре данных количество информации должно быть больше, чем в каждом из отдельно взятых внешних источников. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 11:24 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621адре Уже лучше. Посмотрите: у Вас получилась иерархия страна -> область -> район -> населенный пункт. Логично и оформить ее в виде иерархии (страны - оставить как есть, отдельно). Добавить имена территориальных единиц с учетом страны. Добавить маску, регламентирующую допустимые сочетания территориальных единиц с учетом страны. Дополнитеьная группировка (любые территориальные или экстерриториальные образования) - с учетом типов территориальных единиц. Остаются индексы, улицы и собственно адресация. Уважаемы guest_20040621 не могли бы вы описать связи между таблицами Страны, Области, Районы, Населенные_Пункты. Ну никак не пойму как их так хитро связать с учетом таких требований автора) Многие города делятся на районы. б) Многие города не входят ни в какой район, а являются городами так называемого "областного подчинения" (в каждой области таких не менее двух-трех штук). в) Есть два города (Москва и Питер) федерального подчинения (то есть они даже в область не входят). г) Есть населенные пункты, являющиеся частью других населенных пунктов (ну например, уже упоминавшися здесь Зеленоград) д) Существуют адреса вне населенных пунктов вообще. Например, 133 км такого-то шоссе (есть и похуже). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 11:47 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621Вообще говоря, в хорошей структуре данных количество информации должно быть больше, чем в каждом из отдельно взятых внешних источников. вообще говоря - избыточная информация не плюс, скорее... идеальных источников информации не существует... чем больше данных тем больше ошибок и тем труднее их найти... в общем хватит банальностей по здравом размышлении, я советовал бы бойтись КЛАДР-ом, по крайней мере на первых шагал (допустим на первом релизе) вокруг решения этой задачи нет смысла биться с пеной у рта - по большому буфету таблица Адреса, в данном применении- это справочник, в основных таблицах присутствует только как AddressID, в дальнейшем, в ходе развития приложения, можно будет без труда изменить схему... сосредоточтесь на решении основных задач, потом уже переходите к второстепенным (субуго ИМХО) типо - КЛАДР в access: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 11:48 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
dimichisНу никак не пойму как их так хитро связать с учетом таких требований ИМХО вы тратите время впустую - такой четкой и однозначной структуры не существует, а если бы и существовала - вы не можете гарантировать, что она не изменится уже завтра. и потом... вы же не решаете задучу административно-территориального деления Субъектов РФ и наследуемой соподчиненности топонимических объектов на территории России - ваша прикладная область этого 1 не требует 2 не контролирует т.е. вы пытаетесь решить задачу вообще не относящуюся к разрабатываемому вами приложению... как уже советовали ранее - можно ограничиться "адресом доставки" Country Region City Area AddressLine1 AddressLine2 или как уже советовали ранее можно использовать КЛАДР - его со всеми адресами можно либо купить либо выкачать в сети (сюда, как атачмент, боюсь не влезет) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 12:05 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
типо таки да или как уже советовали ранее можно использовать КЛАДР - его со всеми адресами можно либо купить либо выкачать в сети (сюда, как атачмент, боюсь не влезет) Плиз кинь на мыло Access вариант кладра dimichis@mail.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 12:09 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
> а) Многие города делятся на районы. Это административное деление. Муниципального уровня. > б) Многие города не входят ни в какой район, а являются городами так называемого > "областного подчинения" (в каждой области таких не менее двух-трех штук). Это тоже административное деление. Областного уровня. > в) Есть два города (Москва и Питер) федерального подчинения (то есть они даже > в область не входят). И это административное деление. Федерального уровня. > г) Есть населенные пункты, являющиеся частью других населенных пунктов > (ну например, уже упоминавшися здесь Зеленоград) И это административное деление. Муниципального(?) уровня. > д) Существуют адреса вне населенных пунктов вообще. > Например, 133 км такого-то шоссе (есть и похуже). С этим нельзя бороться с помощью структуры данных, описывающей административно-территориальное подчинение. Это адреса особого типа. > избыточная информация не плюс Я так не считаю. > идеальных источников информации не существует 99,9% баз данных - не источники, а коллекторы. И не информации, а данных. Из данных информацию еще нужно извлечь. > чем больше данных тем больше ошибок и тем труднее их найти Для уменьшения ошибок и придуманы реляционные СУБД, стандарты и приемы проектирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 12:26 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
dimichisвариант кладра dimichis@mail.ru взять http://www.gnivc.ru/downloads/kladr.aspx и импортировать таблицы в акс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 13:18 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621> а) Многие города делятся на районы. Это административное деление. Муниципального уровня. и т.п. Это не только административное деление. Иногда это существенная часть адреса, позволяющая однозначно идентифицировать объект. Точно так же как области и сельские районы. Но от адреса требуется не просто однозначная идентификация строительных сооружений. В большинстве случаев есть необходимость объединения адресов в группы "близколежащих". И в этом плане выделение группы объектов, находящихся в одном административном районе очень полезно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 14:13 |
|
||
|
Структура БД
|
|||
|---|---|---|---|
|
#18+
Bogdanov AndreyНо от адреса требуется не просто. от почтового адреса никогда и не требовалось "однозначной идентификации строительных сооружений" - такое может потребоваться разве что при выписке наряда-задания на снос объекта - чтобы лишнего не наломали ... :) понятие "близколежащий" весьма условно - может быть в ряде случаев достаточно и одной страны, чтобы установить, что адреса "близколежащие" - смотря что за строна и насколько "близко" надо... а уж про мифическое "большинство случаев" и говорить не хочется - расхожий аргумент из разряда спекулятивных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 15:54 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1544703]: |
0ms |
get settings: |
7ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
164ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 207ms |
| total: | 457ms |

| 0 / 0 |
