Посоветуйте как поступить разработчику ПО... 8 / 3522

Хочу сразу сказать что этот топик не пиар. Поэтому скажу только что я с Украины, а к вам обращаюсь потому, что Российский рынок недвижимости уже давно использует Интернет, а у нас он только развивается.
Я работаю менеджером в компании, которая разрабатывает ПО для учета недвижимости (это конечно не основное направление, но не в том суть).
На данный момент всё более остро становится вопрос о импорте данных в базу программы из всевозможных рассылок. Насколько я понял основная масса рассылок производимых интернет-порталами по недвижимости осуществляется в формате *.xls и *.mak (так-ли это?)
Наши пользователи всё чаще говорят о том, что хотят иметь возможность добавлять данные из таких рассылок в общую базу. Но я не представляю как боротся с некорректными данными? Попробую объянить:

В одной рассылке улица Ленина записана как "Ленина ул.", во
второй "ул. Ленина" в третьей вместе с районом "Центральный ул. Ленина". В результате получается ситуация, когда одна и та же квартира может быть записана в базе 3 раза по разным адресам, но имея один фактический. Второе последствие - в списке заявок на покупку указана улица "Ленина" и программа не сообщит вам, что на квартиру по «ул. Ленина» есть покупатель, т.к. «Ленина» не равно «ул. Ленина».
Может стоит разъединить базы? Существует база заполненная риэлторами по результату осмотра квартир (с перекрестным поиском совпадений между покупкой-продажей и
т.д...) и база объектов, полученных из рассылок, в которой есть только сортировка,
поиск и печать.

Как на ваш взгляд, будет ли такое решение оптимальным или есть другой подход?

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

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

П.С.
Или может действительно дать им в руки механизм импорта и пусть импортируют туда всю "Войну и Мир", а там хоть трава не расти :?:

А?

Дмитрий писал(а):
На данный момент всё более остро становится вопрос о импорте данных в базу программы из всевозможных рассылок.
...
В одной рассылке улица Ленина записана как "Ленина ул.", во
второй "ул. Ленина" в третьей вместе с районом "Центральный ул. Ленина"...

Все правильно. Поля в информационные единой базе должны иметь _уникальные_ значения, иначе... это не база, а мусоросборник. Те. "ул.Ленина" должна именоваться (писаться) единым только образом и никак иначе.

Для реализации этого пишутся небольшие программы, называемые в простонародье "конверторами". Т.е. конвертирующие некую информацию (из разных источников) в единый формат, принятый в Вашей Базе.

Суть конверторов проста. В нашем случае это переименовать всех "лениных" в утвержденного нами "ул.Ленина". Я такие программы пишу на Экселе. Он очень хорошо подходит для визуальной работы с текстом. В двух соседних столбцах сотставляются некие таблицы соответсвия (я их называю "библиотеки"). Грубо: в одном поле "что_было", в другом "что_стало_после_замены".

Совершенно аналогичные задачи Вас ожидают со всеми остальными полями. От номера/корпуса дома, до точек/запятых используемых в качестве десятичного разделителя в цифрах.

По хорошему, должен быть один единый конвертор для всех источников инофрмации. На практике этого не получается, т.к. кол-во полей, манера их заполнения, их местоположение и пр. и пр. и пр. у всех репондентов разное. Бороться с этим - невозможно. Как правило базу заполняют неквалицифированные мартышки. Поэтому я и упоминал Игорю, что для написания конвертора нужен ОПЫТ ("опыт" = знание как можно бОльшего кол-ва ошибок, которые может произвести оператор, заполняющий Базу своей фирмы).

===
В идеале эта проблема решается так: Вы разрабатываете свой формат Базы для ваших операторов. Т.е. жестко описываете поля, их расположение, и набор ключей которые могут располагаться в этих полях (тел: "д","+","1","2", балкон: "да","+","л","2","2л"....). Но даже не сомневайтесь, всю информацию придется проверять на ошибки. И не только проверять, а еще и править ее, т.к. в любом поле может оказаться любая ошибка. От неправильного ключа до букв там, где должны быть только цифры.

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

Как правильно указал Алексей, нужно писать конвертер. Который помимо тупого преобразования названия/последовательности полей (типа этаж/этажность) должен приводить к единому написанию:

1) числовые поля (например: дробные через точку, с одним знаком после запятой)
2) поле телефона, например к такому: 123-4567 или 8-903 123-4567
3) поля имеющие текстовые значения из словаря, например: КОМНАТЫ={СМ, ИЗ, СИ}, САНУЗЕЛ={Р,С,2} и т.д.

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

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

Код: внешняя ссылка

Леонов}1}пр > Леонова 1-й пр-д
Леонов}2}пр > Леонова 2-й пр-д
1}пр}Леонов > Леонова 1-й пр-д
2}пр}Леонов > Леонова 2-й пр-д
1}Леонов}пр > Леонова 1-й пр-д
2}Леонов}пр > Леонова 2-й пр-д

Здесь вроде все понятно, например первая строчка означает: искать (во входном поле УЛИЦА) слово, начинающееся на "Леонов", затем 2-е слово "1", затем 3-е "пр". Если Все эти (начала) слов найдены друг за другом - конвертер записывает в выходное поле УЛИЦА стандартизованное значение "Леонова 1-й пр-д".

Или еще пример:

Код: внешняя ссылка

Корчагин       > Корчагина Павла
Косинск}б      > Косинская б.
Косинск}м      > Косинская м.
б}Косинск      > Косинская б.
м}Косинск      > Косинская м.
Коровинск}пр   > Коровинский пр-д
Коровинск}ш    > Коровинское ш.
Кост?маров}наб > Костомаровская наб.
Кост?маров}п   > Костомаровский п.

В последнем случае "?" означает любую букву, чтобы не писать по 2 строчки с разным написанием, типа:

Код: внешняя ссылка

Костомаров}наб > Костомаровская наб.
Костамаров}наб > Костомаровская наб.
Костомаров}п   > Костомаровский п.
Костамаров}п   > Костомаровский п.

В общем, примерно так.
Конечно, такого рода вещи на Excel не пишутся, для обработки больших объемов инфы желательна реализация на C/C++.

Да... Ёксел не везде хорошь. когда мне понадобилась работать с "библиотекой" в 5.000 наименований для обработки 30.000 строчек разом - я обратился к Владиславу (см. месс выше). Он мне спрограммил шуструю прогу на Сях, которую я вызываю при необходимости из Ёксела.

Кстати, в VBA есть подобный оператор - Like. Например:

Кост?маров}наб > Костомаровская наб.

будет записано примерно так:

If текстовая_строка Like(*Кост?маров*наб*) Then ...

Но это не лучшее решение.

Конкретные решения сути дела не меняют. Нужны конверторы. Если все заполняют и присылают данные в единой табличке - один. Если у каждой фирмы свои форматы - по кол-ву фирм. Гимор еще тот (смайл).

Дмитрий, Вы совершенно правильно сомневаетесь. Прежде чем приступать к написанию конверторов, мне кажется, Вам бы надо еще раз как следует подумать, а так ли уж всё это необходимо, будет ли реально использоваться? Зачем объединять чужие непроверенные варианты в собственной базе, ведь все они уже были объединены на каком-нибудь портале? Этим порталом при желании риэлтор и может воспользоваться.

Но если очень хочется зачем-то на всякий случай копить инфу из рассылок, я бы посоветовал Вам это делать в отдельной базе простейшей структуры: <дата поступления> – <содержание> – <источник информации>, где поле <содержание> заполнять путем склеивания всех полей из поступившей записи в одну символьную строку. Это позволило бы Вам не привязываться к разной структуре поступающей информации, а при необходимости всегда можно было бы и найти, что нужно.

а як же внешняя ссылка, проанонсированный ажно в внешняя ссылка и освободивший внешняя ссылка пару недель назад?

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

)

Я попытаюсь обобщить.
1. Импорт из других источников всё-же необходим.
2. Необходимо разделть полную базу и мусорник. Но импорт реализуется и в первом и во втором случае. Решение "где и как мусорить" возлагается на пользователя.
3. В механизме импорта предусмотреть подключение "библиотек-синонимов" в открытом и простом виде (формат *.txt либо *.xml) для реализации предварительного конвертирования данных. При конвертировании предусмотреть возможность выбора библиотеки, с которой работаем. для каждого источника своя библиотека либо общая для всех источников.

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

Еще раз спасибо за профессиональные ответы.....

> Можете ли вы подсказать какую-либо программу, в которой такой механизм реализован?

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