From: | "Daniel Ferrer" <daniel(dot)ferrer(at)ctd(dot)com(dot)ar> |
---|---|
To: | <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | RE: RV: Identificar cadenas similares |
Date: | 2007-12-05 16:27:01 |
Message-ID: | 20071205162703.F3B712E0222@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Carlos por tu pronta respuesta:
Paso a constestarte:
>> En caso consigas ese algoritmo, no lo podras dejar que lo haga por si
solo,deberas usar el resultado para luego hacer un chequeo manual.
Estaba investigando en utilziar SOUNDEX() DIFFERENCE() pero lei que son
aplicaciones solo para ingles.
>> De que tamaño es tu aplicación.
Calculo que me consultas la cantidad de registros en las diferentes tablas
es de aproximadamente 60.000
>> Lo que debes hacer antes que nada es ver porque a ocurrido esto y como
puedes hacer para evitarlo.
El echo tambien esta en que importamos algunos destinatarios a traves de una
interfase con algunos de nuestros clientes y sumado a mala operacion de los
DATA ENTRY llegamos a este punto.
La manera de prevenirlo es utiliziar este mismo algoritmo que ayude al DATA
a encontrar una dato sin que esto signifique que lo escribe tal cual es...
Por ejemplo :
Para hallar la palabra "POSTGRES" que permita la busqueda al colocar
POSGRES, POTGRES, POFTGRES, POST GRES...etc
_____
De: Carlos Alberto Márquez Rey [mailto:carlos_marquez_rey(at)yahoo(dot)com]
Enviado el: Miércoles, 05 de Diciembre de 2007 12:43 p.m.
Para: daniel(dot)ferrer(at)ctd(dot)com(dot)ar
Asunto: Re: [pgsql-es-ayuda] RV: Identificar cadenas similares
Daniel Ferrer <daniel(dot)ferrer(at)ctd(dot)com(dot)ar> escribió:
Estimada Lista:
Apelando a sus experiencias quisiera referirme a un
problema que estamos teniendo en nuestra Aplicación.
La empresa para la cual trabajo es de logística en el
cual se registran todos los destinatarios de los envíos, la idea de
almacenarlos es de brindar a los DATA ENTRY la facilidad de encontrarlos sin
necesidad de ingresar nuevamente los datos ara así evitar errores y acelerar
el proceso de carga de datos.
El problema en cuestión se da que a través de los
distintos centros de distribución la carga de los destinatarios se ha
"ensuciado" de tal manera que ya se torna casi imposible la búsquedas de los
mismos esto debido a la duplicación de tanto de las razones sociales como
así de las direcciones.
Creo que la solución seria AGRUPAR a todos aquellos
destinos (de través de algún algoritmo) el reconocimiento de las "diferentes
cadenas similares".
Este algoritmo también lo debería aplicar en el momento
que se realiza la búsqueda en el formulario de entrada de datos.
Adjunto algunos ejemplo de repeticiones de razones sociales de destinos
BRIGHTON-BEST SOCKET SCREW SRL
BRIGHTON - BEST SOCHET SCREW SRL
BRIGHTON-BEST SOCKET SCREW S.R.L.
Adjunto algunos ejemplo de repeticiones de direcciones de destinos
KLOSERMAN 2100
KLOSTERMAN 2100
KLOSTERMAN 2100
KOSTERMAN 2100
S.O.= Linux Debían 4.0 Etch
Lenguaje= Java
DB= Postgres 8.2
A la espera de haber sido claro en la exposición del problema les agradezco
de antemano.
Atte.
___________________________
ASC Daniel Ferrer
Gerente de Sistemas - CTD SRL
Rosario - Argentina
<BLOCKED::mailto:sistemas(at)ctd(dot)com(dot)ar> mailto:sistemas(at)ctd(dot)com(dot)ar
___________________________
En caso consigas ese algoritmo, no lo podras dejar que lo haga por si solo,
deberas usar el resultado para luego hacer un chequeo manual.
La opción seria ir migrando la data correspondiente a las empresas que seran
dadas de baja a la empresa que quedara en la BD
De que tamaño es tu aplicación.
Lo que debes hacer antes que nada es ver porque a ocurrido esto y como
puedes hacer para evitarlo.
Bueno es lo que se me ocurre por el momento.
Quiza alguien tenga una mejor idea.
Carlos Márquez
_____
Comparte video en la ventana de tus mensajes (y también tus fotos de
Flickr).
Usa el nuevo Yahoo! Messenger versión Beta.
Visita http://e1.beta.messenger.yahoo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Nicolás Domínguez Florit | 2007-12-05 16:27:14 | nuevo servidor, que conviene? |
Previous Message | juan guzman | 2007-12-05 16:11:59 | Problema con log de transacciones |