Кошмар

← →
Vikuksa (2002-09-20 15:22) [0]

Поможите кто может!!!!!!!

В базе есть текстовое поле - адрес.
А нужно посчитать кол-во людей проживающих по одному адресу, НО
этот (пакостный) адрес могли забивать разные (пакостные)люди в следствии чего он и написан по разному!!!

Записей порядка 60 000!
Прям не знаю че делать!

← →
Василич (2002-09-20 15:27) [1]

Для этого в SQL есть конструкция WHERE ... LIKE.. . А еще лучше привести все данные в нормальный вид.

← →
Vikuksa (2002-09-20 15:35) [2]

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

← →
Василич (2002-09-20 15:39) [3]

Ну, предположим, в базу забиты два человека - один на улице О.Кошевого, другой - на ул. Олега Кошевого (то есть, оба на одной улице). Чтобы узнать, сколько народу живет на этой улице, пишем запрос типа
SELECT COUNT(*) FROM dbo.PeopleBase WHERE StreetName LIKE %Кошевого.

А чтобы привести все в нормальный вид, открываем SQL QA и пишем там
UPDATE dbo.PeopleBase
SET Streetname="ул. О.Кошевого" WHERE Streetname LIKE %Кошевого

← →
Vikuksa (2002-09-20 15:45) [4]

понимаешь в этом поле все и город и улица и дом и кв.!!!

← →
sniknik (2002-09-20 15:46) [5]

а если етот подлый юзер забил английскую о вместо руской? вот и нет олежки :о)). все одно большую часть вручную придется :-((.

← →
sniknik (2002-09-20 15:47) [6]

реструктуризацию базы обязательно!!!

← →
Vikuksa (2002-09-20 15:49) [7]

Кто ж мне даст ее реструктуризировать!

← →
Johnmen (2002-09-20 15:50) [8]

Дорогая Vikuksa, Вам просто необходимо в корне пересмотреть структуру своей БД ! Предварительно изучив правила нормализации.
Тогда таких вопросов не будет...
:-))))))

← →
Vikuksa (2002-09-20 15:52) [9]

ЭТО НЕ МОЯ Б/Д! мое дело по ней запросы строить (когда начальство велит).

← →
Johnmen (2002-09-20 16:04) [10]

Тогда надо сделать так, чтобы винт с БД рухнул, и рухнул навсегда ! После чего спокойно приступайте к разработке новой БД.
По-другому данная проблема полноценного решения не имеет !

← →
Vikuksa (2002-09-20 16:06) [11]

потом меня рухнут, это меня не привлекает, из-за одного запроса!

← →
sniknik (2002-09-20 16:15) [12]

запрос в таком виде какая база сейчас решения не имеет проще для шефа килера пригласить. :о))

← →
Vikuksa (2002-09-20 16:18) [13]

у меня начальник хороший, это у него плохой( т.е. начальник у моего начальника плохой!)

← →
sniknik (2002-09-20 17:24) [14]

ну ну вам виднее какой у него... :о))))))
извиняюсь но очень смешно получилось!

← →
Wolf226 (2002-09-20 17:33) [15]

На стол начальника начальника бумажку. Тип такой:

Вследствии недостаточной нормализации таблицы БД "Место проживания" при проектировке, а также отсутствия строго стандарта ввода поля "Адресс", не существует автоматизированного
решения поставленной задача.

Для нормализации БД требуется.
1. Модификация таблицы "...."
2. Ручная Нормализация Информационной Сущности "Адресс".

Вследствии большого объема работ по п.2. (60 000) порядка
2000 чел*час, Прошу привлечь, после выполнения мною п.1. в помощь ...

:-(

Не пройдет. Увидев 2000 чел*ч. Начальник поубивает вас.
Хотя можно попробовать.

← →
Anatoly Podgoretsky (2002-09-20 17:46) [16]

Vikuksa © (20.09.02 15:52)
Делай запрос по существующей, и пусть думают, что с такой базой делать, а бумажку на стол обязательно, иначе задача решения не имеет

← →
Anatoly Podgoretsky (2002-09-20 17:51) [17]

К пункту 1 и 2 возможно потребуется добавить пункт 3 - переделка существующего программного обеспечения

← →
Wolf226 (2002-09-20 18:10) [18]

Да, я подразумевал в п.1. переделку существующего программного обеспечения, но забыл указать. Ведь только после этого можно приступать к п.2.

Vikuksa, кстати, за сколько можно одну запись будет ввести?
Я исходил из 2 минут.

← →
xxxXXXXXX (2002-09-20 20:04) [19]

праверь почту

← →
VAleksey (2002-09-21 07:54) [20]

ну и еще
SELECT COUNT(*) FROM dbo.PeopleBase WHERE Upper(StreetName) LIKE %КОШЕВОГО.
так все - таки поудобнее будет

← →
AlexanderB (2002-09-21 10:27) [21]

1. Разбить по полям все равно нужно.
Исходя из свой БД:
индекс
нас. пункт
улица
назв. улицы
дом
корпус/строение
кв., офис
примечание
Полную структуру для адреса не привожу, иначе "поплохеет"
Хуже, когда в адресе присутствуют слова "озеро", "остров", "25-км" и т.д. Приходится приводить все к единому стандарту.
Была такая же проблема как и у нас. Пришлось ввести промежуточную таблицу и написать "анализатор". Все адреса программа разложила по полочкам. Если что-то он не понимала, то выдавала сообщение "..." и правку вносил вручную. После "нормализации" обновил структуру, заполнил новыми данными. Никого не спрашивал и не упрашивал. А сейчас все работает и ни у кого вопросов не возникает.
2. Далее следовало бы вводить автоматом (из списка) назв. улицы, а исходя из полного адреса присваивать почт. индекс. И т.д.

Под лежачий камень вода не течет

← →
Севостьянов Игорь (2002-09-21 16:09) [22]

1. Действительно нормализацию БД прийдется делаь практически вручную
2. Без реконструкции (перепланирования БД и ПО) не обойтись, т.к. сталкиваться с этой проблемой будешь в дальнейшем
3. Для начальства: При не правильной разработка БД и без ее стандартизации - мы теряем до N-часов рабочего времени и соотвественно снижаем нашу работоспособность, что приводит к потере данных и снижению ПРИБЫЛИ (это главное слово)
4. Просто надо дать понять начальству, что при улучшении всей структуры ПО+БД мы увеличим показатели... Скупой платит дважды...
Если проведен такие изменения сейчас, когда это не так болезненно (данных меньше, чем, например, через год), то в будущем мы сможем не только обойти наших конкурентов, а и найти применение нашим данным (самый ценный и дорогостоящий материал - это информация)...
5. У меня в одно время, когда я пришел работать в одну фирму - была БД, где адрес был именно в таком вот виде - итог при распечатке, тогда выводила по две и более одинаковых фирм якобы по разным адресам. Что было сделано ? Была перелопачена БД на удаление и приведение к нужному виду всех данных и составлена новая структура ПО и БД - в итоге полный порядок при внесении данных (хаос ушел далеко) и люди, которые работали по данным распечаткам перестали жаловаться... Начальство осталось довольно - но не получив за этот колосальный труд (5 тыс фирм -адресов еще больше) ни копейки премии я ушел на другое место (правда на следующей работе и з/п была больше)

← →
virgo (2002-09-23 08:08) [23]

Если будете изменять структуру БД, советую посмотреть какие поля существуют в адресном классификаторе ГНИ (налоговой инспекции). Этим классификатором теперь бесплатно пользуется вся страна. Помимо всего, его данные можно использовать для корректного ввода адреса.

← →
VikOss (2002-09-23 11:06) [24]

Уважаемый Викукса ! Здесь есть один выход, но он немного громоздкий. Но всё же он более реален чем привлечение 2000 чел.
Необходимо обратиться к специалисту по экспертным системам(искуственный интеллект). Можно написать небольшую программку(экспертную систему), которая будет различать из Вашей каши все необходимые данные...ЭТО РЕАЛЬНО !

← →
handra (2002-09-23 11:07) [25]

Севостьянов Игорь ©> Еще добавить призник владения, а также поле сооружение.
Вся беда в том, что существуют т.н. "альтернативные адреса", т.е. один дом может иметь два, три и более адресов, что еще более усложняет задачу.

← →
3JIA9I CyKA (2002-09-23 12:08) [26]

Для начала нужно оъяснить начальству, что Вы готовы (и даже рады) писать любые запросы. После чего спросить, какие условия должны выполняться, для того, чтобы можно было считать, что адреся одинаковы. Попросите написать это в качестве задания. Делайте именно то, что написано. Это защитит и Вас (от несправедливых обвинений в невыполнении поставленной задачи), и Ваше RукоVодство (от возможных / невозможных / надуманых / злонамеренных проявлений саботажа).
Проявите твёрдость, причиной которой является Ваше истовое желание работать на благо заказчика! 8)

← →
MaratFromTomsk (2002-09-26 08:05) [27]

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

А кто мешает к уже существующим адресам добавить
еще несколько таблиц,
в которой все таки прописать нормальный структурированный адрес.

В нащей системе мы храним это примерно в следующем виде:

// Типы регионов (РФ, республика, край, область, город, и т.п.)
REGIONTYPE = (
ID : INTEGER;
NAME : STRING;
);

// Допустимые входимости одних типов регионов в другие
REGIONCANBEIN = (
ID : INTEGER;
NAME : STRING;
REGION : REGIONTYPE; // Тип региона
CANBEIN : REGIONTYPE; // Может входить в ...
);

// Почтовое отделение
POSTOFFICE = (
ID : INTEGER;
NAME : STRING;
PARENT [Предок] : POSTOFFICE; // Сортировочное отделение
IND [Индекс] : integer;
);

// Адрес
ADDRESS = (
ID : INTEGER;
NAME : STRING;
PARENT [Предок] : ADDRESS;
REGIONTYPE [Тип региона] : REGIONTYPE;
POSTOFFICE [Почтовое отделение] : POSTOFFICE;
COD [Код ГНИ] : string(40);
);

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

Преобразование данных из существующего формата - это работа,
и ее надо делать, если вы хотите выполнять такие запросы.
иначе полное соблюдение приницпа GIGO
(Garbage Input Garbage Output)
Мусор на входе мусор на выходе.

← →
Anatoly Podgoretsky (2002-09-26 08:58) [28]

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

← →
MsGuns (2002-09-26 11:32) [29]

У меня есть опыт решения очень похожей проблемы. Лет несколько назад пришлось нормализировать БД "Население", где было более 250000 строк и полный бардак с адресами.
Никаких автоматических методов для ОДНОЗНАЧНО КОРРЕКТНОГО ПРЕОБРАЗОВАНИЯ (LIKE, исск.интеллект и пр.) не существует !
С их помощью, возможно, Вы и нормализуете 99% данных, но что делать с оставшимся 1 ? Искать его в БД из четверти миллиона записей ?
Поэтому делается так:
Получаете "выжимку" из реальной БД. В данном случае одно поле "Адрес". В эту таблицу надо добавить 6 доп.полей:
- Номер записи (уник.ключ)
- Код улицы
- Название улицы
- Номер дома
- Номер корпуса
- Номер квартиры
У Вас получается "таблица конвертации" (ТК)
Далее пишете программу, которая по известному шаблону просканирует (построчно) все записи, выделяя в новые поля значения из исх.строки.
(Например, Номер квартиры определяется как посл-ть цифр, следующих за кл.связкой "кв." или "Кв." или "кв")
После этого вручную (глазками и ручками, да-да !) просматривается рез-т и определяется, достаточно ли оптимален примененный Вами алгоритм, если нет, то улучшаете его и по новой всю ветку.
Когда рез-т автом.преобразования более-менее приемлим, передаете просмотр и коррекцию операторам. (Если таковых нет, то значит оператор - это ВЫ !)
Главное на этом этапе - отделить улицу от дома и кв.

Этап 2
---------
Нормализация улиц

← →
Владислав (2002-09-26 12:05) [30]

У меня есть программка на Perl, которая разбирает такие вот поганые адреса в разные поля. Одно но. Нужно знать регулярные выражения. Пиши по почте или стучи по аське. Скину.

← →
MsGuns (2002-09-26 12:09) [31]

Поправка к тексту

Получаете "выжимку" из реальной БД. В данном случае одно поле "Адрес". В эту таблицу надо добавить 6 доп.полей:
- Номер записи (уник.ключ)

В "выжимку" надо, естественно, добавить и ключ (Код или ФИО или что там у Вас однозначно идентифицирует человека). Это ключ и будет Уникальным номером записи (УНЗ)

Этап 2 Нормализация улиц
--------------------------
По полю "Старый адрес", из которого на первом этапе была удалена информация о доме и квартире, делается выборка уникальных с созданием доп.поля

Select distinct T.OldAddr, MAX(T.OldAddr) as NewAddr From TmpTable T GROPUP BY T.OldAddr

Полученная таблица сохраняется в TmpStr1

У нас, как это ни странно, из 250000 записей выбралось что-то порядка нескольких тысяч (Видимо при наборе старой базы срабатывал метод "дважды на одни грабли", т.е. когда одна и та же ошибка, в т.ч.грамматическая, делается многажды).
Далее из адреса New убираются ВСЕ пробелы, разделители, и все лат.буквы заменяются на русские ("С" к примеру одинаково отображается и в кириллице, и в латинице).

Select distinct S.NewAddr, MAX(S.NewAddr) as NewAddr2
From TmpStr S
GROPUP BY S.NewAddr

Полученная таблица сохраняется в TmpStr1

Кол-во записей опять должно существенно уменшиться.
Теперь опять "глазки-ручки".

Еще раз Select по описанной схеме и сохранение в TmpStr2

Полученная таблица сохраняется и слева дополняется полем "Идентификатор улицы", сначала пустым. По идее мы получаем справочник улиц, пока правда с незаполненным ID.
Опять "глазки-ручки". Однако при вводе ID на проверять наличие ключа (Метод TDBEDataSet.LookUp в самый раз !)

После этого поле ID делается ключом (реструктуризация таблицы) - и справочник готов !

Этап 3
--------
А теперь ступенчатая перекодировка в обратном порядке !

← →
ustas (2002-09-26 12:39) [32]

Свои 5 копеек... Самое приличное решение - у virgo. Сам нарывался на такую задачу, все кончилось использованием того самого справочника. Нужен сам справочник - пишите.

← →
MsGuns (2002-09-26 13:24) [33]

ustas (26.09.02 12:39)
>Самое приличное решение - у virgo.

Не совсем удачная реплика. Поясняю:

Во-первых. Автор сабжа живет не в Украине, ГНУ у них нет. Хотя, если в России существует что-то подобное (классификтор районов, областей и пр.), то его, конечно, можно использовать. Однако проблему улиц никакой общегосударственный справочник не решит. Поэтому совет vigro можно использовать как ДОПОЛНЕНИЕ, но никак не РЕШЕНИЕ.

Во-вторых.Судя по размерам БД автора, это скорее всего по району, а там код города, области (республики, страны и т.п.), что в данном случае как рыбке зонтик. Оттуда можно взять только ИНН (Инд.нал.номер), но 2 вопроса в связи с этим:
1.Кто будет для 60 000 человек вводить ИНН (занятие премерзкое, доложу я Вам, номер состоит из кучи цифр) ?
2.Нужен ли этот ИНН для "начальства" ?

← →
toxa (2002-09-26 14:01) [34]

sniknik © (20.09.02 15:46)
а если етот подлый юзер забил английскую о вместо руской? вот и нет олежки

Изв что не в тему.
А как сделать чтобы при фокусе одного эдита шрифт был-Ru,
а др-En и никакой подлый юзер его не поменял-бы пока он в
фокусе

← →
MsGuns (2002-09-26 14:06) [35]

>toxa (26.09.02 14:01)
>А как сделать чтобы при фокусе одного эдита шрифт был-Ru,
а др-En и никакой подлый юзер его не поменял-бы пока он в
фокусе

Используй MaskEdit или обрабатывай OnDataChange и сам убирай неверно введенный символ. Ну а выбор фонтов по св-ву Font

← →
toxa (2002-09-26 14:43) [36]

← →
Vikuksa (2002-09-26 16:01) [37]

Ребята спасибо большое за такое кол-во советов , но я сделавши проще!

Большое Вам спасибо!

← →
MsGuns (2002-09-26 16:07) [38]

>Vikuksa © (26.09.02 16:01)
>Ребята спасибо большое за такое кол-во советов , но я сделавши проще!

>Большое Вам спасибо!

За большое спасибо, конечно, спасибо тоже большое, но все же в приличном обществе декларировать свои решения. Будьте добры, раскойте на Вашу тайну ! Как вы "сделавши проще" ?

← →
Vikuksa (2002-09-26 16:14) [39]

Создала таблицу с неинформац. словами : ул., улица, РФ, г. и т.д.
Потом убрала в поле Индекс и начальные пробелы.
Затем те слова из табл., и уж опосля этого вообще все пробелы в поле, получилось более - менее рабочая информация.

← →
MsGuns (2002-09-26 16:34) [40]

Понятно. Типа решения проблемы. Если шефа устроит "прикидочный" стиль результатов выборок, то и так сойдет !

Кошмар Найти похожие ветки