![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Table => Filter? [D7, dBase, FoxPro]
Jet © (2004-05-27 17:25:00)Нужно составить следующий фильтр для таблицы:
Имеется таблица .dbf (FoxPro) с полем Fam, Name и т.д.
Ее нужно отфильтровать по первым пяти буквам фамилии и трем первым
буквам имени, т.е. если есть записи:
1 Иванов Петр
2 Иванова Петр
3 Ивашкин Петр
4 Ивашкин Пятр
То считать одинаковыми записи 1 и 2:
(Ивано)в (Пет)р
(Ивано)ва (Пет)р
Но разными 1,3,4:
(Ивано)в (Пет)р
(Ивашк)ин (Пет)р
(Ивашк)ин (Пят)р
или 2,3,4
(Ивано)ва (Пет)р
(Ивашк)ин (Пет)р
(Ивашк)ин (Пят)р
На выходе должно быть:
1 Иванов Петр
3 Ивашкин Петр
4 Ивашкин Пятр
или
2 Иванов Петр
3 Ивашкин Петр
4 Ивашкин Пятр
Т.е. фактически вывести уникальные записи по первым 5 буквам фамилии и
первым 3 буквам имени. Помогите кто знает.
Anatoly Podgoretsky (2004-05-28 11:25:00) [1]Соловьев © (28.05.04 10:51) [26]
Считай приведенный в вопросе пример как раз суррогатным ключом, поскольку там ничего естественного нет.
Суррогатные ключи обеспечивают только уникальность записи и ни как в данной ситуации не помогает, правда в данной ситуации ничего не поможет. Поскольку
Ивашкин Саша
Ивашкин Паша
могут быть как один и тот же человек, так и разные люди. Вопрос решается только административными путями, технические только в помощь к ним.
Sergey13 (2004-05-28 11:01:00) [2]2Соловьев © (28.05.04 10:51) [26]
> да вроде фамилия та же но - это уже другой клиент. поэтому когда будет менятся, надо заводить новую запись.
Надо, кто спорит то? Это другой клиент. И старого оставить, с кодом 3333333. Если это критично для системы, то подумать как их логически объединять, если нет - то и так сойдет. 8-)
А паспорта... У меня в 39 лет уже второй (российский) у жены 3 или 4 (два раза замужем - причем второй раз удачно 8-)....
>но это тема для длинного спора...
Во-во... 8-)
Соловьев (2004-05-28 10:51:00) [3]
> Меняться может все что угодно. 8-( Но это вопрос из другой
> оперы.
Такой случай: был клиент и бул у него код например 3333333, все документы так и оформлялись, а потом например он сменил вид экономической деятельности и у него уже другой код, да вроде фамилия та же но - это уже другой клиент. поэтому когда будет менятся, надо заводить новую запись.
Хотя, наверное, лучше сделать суроганый ключ, а не естественный, но это тема для длинного спора...
Sergey13 (2004-05-28 10:45:00) [4]2Соловьев © (28.05.04 10:19) [23]
>почему? можно и ПК
Можно. Но не нужно, по моему глубокому убеждению. Ибо в этой стане практически нет устойчивых реквизитов. Меняться может все что угодно. 8-( Но это вопрос из другой оперы.
Anatoly Podgoretsky (2004-05-28 10:35:00) [5]Если при этом еще и нет ссылочной целостности, то красиво будет после удаления.
Соловьев (2004-05-28 10:19:00) [6]
> Только не ПК, а просто уникальность.
почему? можно и ПК
Sergey13 (2004-05-28 10:18:00) [7]2Соловьев © (28.05.04 09:56) [21]
>... что разработчик не придумал PK(паспорт, код налоговой, код страхованитя и т.п.)
Только не ПК, а просто уникальность.
2Jet © (27.05.04 18:03) [16]
>Было у меня две базы. Одна большая (~200 метров), другая небольшая (~1 метра).
А больше таблиц никаких нет? Просто список физ.лиц.? Что то на эти записи ссылается? Ну там деньги или еще что? А то ведь можно одного нечаянно миллионером сделать, друго нищим. 8-)
Соловьев (2004-05-28 09:56:00) [8]ИМХР, изначально не правильно была заработана структура БД. Оператор не виноват, что разработчик не придумал PK(паспорт, код налоговой, код страхованитя и т.п.). Было бы это ключевое поле - никто не смог бы ввести одного и того же человека дважды. И такие вопросы еще должны решатся на этапе проеткирования, а не в процессе работы проги.
Jet (2004-05-27 20:57:00) [9]Может кто подкинет еще идею?
Спасибо.
Anatoly Podgoretsky (2004-05-27 19:03:00) [10]Jet © (27.05.04 18:45) [18]
Не факт, могут быть обе верные.
Предоставь право решать оператору, а ему выдай список
Jet (2004-05-27 18:45:00) [11]Начну сначала. Было у меня две базы. Одна большая (~200 метров), другая небольшая (~1 метра). Мне нужно было вывести все записи из большой таблицы, которых нет в маленькой. Я это сделал вложенным запросом:
SELECT * FROM T1 WHERE NOT EXISTS (SELECT * FROM T2 WHERE
T2.Lname = T1.R08 and T2.Fname = ap.R09 and .... ) and T1.R17 <> "111" and ap.R17 <> "" and T1.R17 <> " " order by R18,R08');
Сделал я это. Сохранил все аккуратненько по разным текстовым файликам. А потом увидел, что есть например такое:
Иванов Иван Сергеевич
Ивановь Иван Сергеевич
Записи, согласитесь весьма одинаковы (ошибки набивщиков), и одна из них не нужна. Вот теперь и суть отфильтровать эти записи по ключу:
Фамилию по первым 5 буквам, имя по 3 буквам, отчество по 3 буквам + дата рождения из одной записи. Накроет конечно не всех, но очень неплохо сработает.
Других идентификационных данных нет..((
HSolo (2004-05-27 18:03:00) [12]Чистить таблицы "на автопилоте", без человека, это, по-моему, для любителей острых ощущений, вроде русской рулетки :)) Можно предоставить человеку сервис, что-нибудь вроде "отбор похожих записей" (по like, нечеткий поиск... по вкусу), но решение об удалении записи должен принимать человек, а не компьютер. По-моему, так (с) Винни-Пух.
А если на очищаемую таблицу кто-то ссылается - то нужен еще механизм перевешивания ссылок с удаляемой записи на правильную.
Jet (2004-05-27 18:03:00) [13]Начну сначала. Было у меня две базы. Одна большая (~200 метров), другая небольшая (~1 метра). Мне нужно было вывести все записи из большой таблицы, которых нет в маленькой. Я это сделал вложенным запросом:
SELECT * FROM T1 WHERE NOT EXISTS (SELECT * FROM T2 WHERE
T2.Lname = T1.R08 and T2.Fname = ap.R09 and .... ) and T1.R17 <> "111" and ap.R17 <> "" and T1.R17 <> " " order by R18,R08');
Сделал я это. Сохранил все аккуратненько по разным текстовым файликам. А потом увидел, что есть например такое:
Иванов Иван Сергеевич
Ивановь Иван Сергеевич
Записи, согласитесь весьма одинаковы (ошибки набивщиков), и одна из них не нужна. Вот теперь и суть отфильтровать эти записи по ключу:
Фамилию по первым 5 буквам, имя по 3 буквам, отчество по 3 буквам + дата рождения из одной записи. Накроет конечно не всех, но очень неплохо сработает.
Других идентификационных данных нет..((
Соловьев (2004-05-27 17:56:00) [14]
> они в принципе одинаковы
нету какого-то поля которое точно идентефицирует человека? код налоговой допустим? или паспорт? По имени и фамилии - опасно очень.
Соловьев (2004-05-27 17:54:00) [15]
> Мне нужно почистить большую базу ~200 метров
> Просто там слишком много всяких Ивановых и т.д., у которых
> по ошибке набита какя-нибудь буква не так (дальше 5 буквы),
> а они в принципе одинаковы, вот и надо их "истребить" по
> записям..))))
ооо, знакомая ситуация...
опасна и трудна...
HSolo (2004-05-27 17:53:00) [16]>Jet © (27.05.04 17:49) [10]
А Вы уверены, что там нет какого-нибудь Ивановского или Иванопуло? У которого и после 5-й буквы все нормально?
Sandman25+1 (2004-05-27 17:52:00) [17][8] Vlad © (27.05.04 17:47)
Через фильтр очень сложно.
PS. Точнее, я совсем не представляю, как...
Sandman25+1 (2004-05-27 17:51:00) [18][10] Jet © (27.05.04 17:49)
Это очень опасно. Так можно и Иванова с Ивановичем спутать.
Jet (2004-05-27 17:49:00) [19]Мне нужно почистить большую базу ~200 метров
Просто там слишком много всяких Ивановых и т.д., у которых по ошибке набита какя-нибудь буква не так (дальше 5 буквы), а они в принципе одинаковы, вот и надо их "истребить" по записям..))))
Соловьев (2004-05-27 17:48:00) [20]Ах, блин, что-то я стал вообще не внимательным, действительно есть FIO
тогда
select *
from table
where family like :p1||'%' and name like :p2||'%'
где p1 и p2 - параметры заполняешь в проге