|
|
|
Структура БД
|
|||
|---|---|---|---|
|
#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?fid=32&msg=34366036&tid=1544703]: |
0ms |
get settings: |
6ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
193ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 213ms |
| total: | 466ms |

| 0 / 0 |
