|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
Поддержу vmag - сделать адрес одной текстовой строкой. В дальнейшем, если нужно будет, то этот адрес можно распарсить и делать с ним, что угодно. Это даёт ещё одно преимущество - можно накопить статистику по тому, как люди записывают адрес и уже на основе этой информации рождать новую версию с таблицами улиц, домов, районов и всего прочего. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 10:11 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
graycode В таком случае нужно делать логику read only для адресов использованных в заказах это ни к чему, при сборе статистики, опять собираем строку и сравниваем со строкой в заказе, если нет совпадения, то и не учитываем в статистике... соответственно если для сбора в статистике нет совпадений в заказах, то по этому адресу ничего и не доставлялось. А если была корректировка неправильного адреса, то она была и там и там, иначе заказ не был бы обработан ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 10:29 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
softwarer Александр1918 К сожалению в данном случае, это неизбежность. Нет. Александр1918 Из старой базы будет перенесено порядка 700к записей заказов + прогнозируемый рост 200 - 250к записей заказов в год. О чём и речь. Миллион записей был приличным объёмом в начале двухтысячных. Сейчас, когда я делаю пробные примеры на своём ноутбуке - делаю таблички по десять миллионов, иначе всё срабатывает слишком быстро. Значит это мое субъективное. Впервые работаю с базой такого размера. graycode Александр1918, ... На сколько я понял у вас заказчики которые заказывают какую либо услугу, заказчики внутренние корпоративные или внешние? Если внешние, то им очень глубоко фиолетовы все ваши таблицы и id, заказчик хочет заказать услугу, но адреса в вашей системе нет, что ему делать?... Заказчики внешние. Выше я описал предполагаемую логику работы формы адресов. Александр1918 ...При внесении или изменении значений в полях улицы или номера дома и сохранении формы (заказа или юзера), нужно делать проверку, есть ли в справочнике домов указанный адрес. Если есть, то вносить ID дома в таблицу заказа/юзера, если нет, то создавать новую запись в справочнике домов, а потом вносить ее ID в таблицу соответствующего заказа/юзера... Юзеру будет доступен только справочник улиц. Номер дома он будет вносить вручную, поэтому ситуации с отсутствием адреса пользователя в справочнике не случится. graycode ... правда он пока не осознал что заниматься раскидываением строений, владений, домов и их корпусов по районам он буде сам и ручками. Справочник домов города с привязкой к районам будет готовится какое-то время отдельно. Само приложение стартует без этого функционала. Но позже его нужно будет добавить. Последняя схема сделана с учетом этого требования. Справочник домов будет наполнятся по мере поступления заказов, а когда будет готов полный справочник с привязкой районов, то из него можно будет взять недостающие дома, а уже существующие связать с районами. Пока не вижу в этом плане ничего ужасного. Я что-то упускаю? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 10:49 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
Александр1918Я что-то упускаю? Выбор из справочника - медленнее прямого ввода. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 13:11 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
vmag опять собираем строку и сравниваем со строкой в заказе Такой вариант мне совсем не нравится, очень много дополнительных и плохо контролируемых действий включающих не сильно четкую логику парсинга при любых манипуляциях с адресом, потом взяли и изменили формат собираемой строки, а потом еще подкорректировали и т.д... ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 13:31 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
Александр1918 Заказчики внешние. Значит обязать пользователя обращаться в отдел НСИ для добавления информации или исправления косяков в нормативно-справочной информации нет, поэтому пользователи сами должны вводить свои адреса, страна и регион из справочников (можно проставлять автоматически используя настройки профиля или геолокацию), населенный пункт уже вводится руками, дальше вообще одна строка улица-строение-квартира, почтовый индекс - отдельное поле. На счет ничего ужасного, если отдела НСИ и выделенного ответственного человека нет, то актуальность классификатора адресов вы будете поддерживать сами. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 13:40 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
Stanislav P сделать адрес одной текстовой строкой. В дальнейшем, если нужно будет, то этот адрес можно распарсить и делать с ним, что угодно... Вы когда-то занимались подобной задачей: парсинг адресов?) Я вот занимался, врагу не пожелаю. Если возможно сразу заполнять отдельно, то лучше это сделать. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2020, 13:07 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
MegabyteЯ вот занимался, врагу не пожелаю. Именно поэтому адреса и не надо парсить, а использовать как есть по назначению. И нет, территориально-географическое деление это не назначение адреса. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2020, 13:13 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov MegabyteЯ вот занимался, врагу не пожелаю. Именно поэтому адреса и не надо парсить, а использовать как есть по назначению. И нет, территориально-географическое деление это не назначение адреса. Не до конца понимаю ваш комментарий. А как, в вашем случае, делать территориально-географическое деление, если не по адресу? И что это за данные такие, как называются? Парсить(разбивать на элементы) или не парсить адрес, думаю, зависит от задачи. Для моей задачи это было необходимо. Ко мне и обратились после того, как запустили систему, где поиск был по строке в адресе. Т.е. это была база уже готовых адресов. Там был поиск по адресу + планировалась различная аналитика в разрезе разных атрибутов адреса: округ, регион, город, улица. Работа с целым адресом-строкой, во-первых, снижала корректность поиска(каждый пишет, как он хочет), во-вторых, было жутко медленно даже не небольшой. Про аналитику клиент даже не заикался изначально. Сложность парсинга была связана с бардаком в данных адреса. Приходилось так же корректировать типовые косяки. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2020, 15:00 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Именно поэтому адреса и не надо парсить, а использовать как есть по назначению. Много лет назад мой научный руководитель сказал: "Главное различие между математиком и инженером в том, что математик делает то, что можно, так, как нужно, а инженер делает то, что нужно, так, как можно". ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2020, 15:02 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
MegabyteИ что это за данные такие, как называются? Так и называются: административно-территориальное деление. Человеческой логике не поддаётся, поэтому справиться с ним может только специально выделенный бюрократ или модное нынче "глубокое машинное обучение". Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2020, 15:15 |
|
Вопрос по проектированию БД
|
|||
---|---|---|---|
#18+
Бообще-то ни перво ни второе, вам в самом первом ответе посоветовали почитать про нормализацию данных. Второе вообще отстой. Опредилите сначала , что у вас первично , а что вторично. А потом от туда и скачите. в первом недостаток зачем связь по улицам, это нужно если клиент, имеет несколько адресов, но для этого заведите отдельную таблицу где для клиентов будет таблица адресов доставки. Если каждый новый адресс клиента как новый клиент регистрироваться будет, то эта связь опять бессмыссленна. Второй вариант вообще только для отчетов полезен. для системы он вообще как собаке 5 нога. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.11.2020, 10:53 |
|
|
start [/forum/search_topic.php?author=Curr93&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
others: | 5828ms |
total: | 5996ms |
0 / 0 |