Una forma de abordar este problema puede ser:
adoptan tres vistas de direcciones/números de teléfono/códigos postales, etc.
La primera vista es el de direcciones (por ejemplo) como múltiples líneas de texto.
La segunda vista es la de las etiquetas de dirección (más sobre esto a continuación).
La tercera vista es el de reglas de validación para direcciones
Los otros componentes que son necesarios para este enfoque son un procedimiento genérico (clase/disparo) para la validación; una rutina de formateo para propósitos de impresión; y una base de reglas, junto con un mecanismo de administradores para actualizar las reglas de validación. Una regla de "captura" que dice que esta es una dirección válida, se ha validado manualmente, incluso si no cumple con ninguna de las reglas de la base de reglas.
Los componentes: 1 La dirección se compone de varias líneas, cada una de las cuales tiene un número de secuencia asociado y un número de etiquetas (generalmente una). También es posible asociarlo con una línea de dirección, el conjunto de reglas y versiones de reglas con las que se validaron, pero este es un refinamiento que depende de las tasas de actualización/inserción/cálculo.
2 Las etiquetas de dirección son cosas como ciudad; pueblo; número de casa; e identifica las diferentes líneas de una dirección. Es posible tener una línea de dirección que no tenga ninguna etiqueta, pero en este caso, solo son posibles las búsquedas genéricas (por ejemplo, para Nueva York) en el conjunto completo de líneas. Las búsquedas de "Ciudad = Nueva York") no son posibles.
3 Reglas redactadas en un idioma específico del dominio. Esto podría ser una expresión regular; un idioma específico para ti; su lenguaje de desarrollo normal (aunque este es probablemente el enfoque menos útil, ya que los lenguajes de programación pueden tener dificultades para representar consecuentemente y con precisión reglas del tipo de las que estoy hablando. Un ejemplo de reglas representativas podría ser (lidiando con su descripción de códigos postales de EE.UU.) - los cinco primeros caracteres deben ser dígitos
los primeros cinco caracteres representan un "código de área"
el código postal debe ser la última línea de una dirección
el... las reglas se dividirán en grupos y conjuntos (por ejemplo, direcciones de EE. UU.). Las reglas deben poder referirse a otras reglas, así como a los datos de dirección.
Su rutina de validación debe tomar las líneas de una dirección y aplicarle las reglas (generalmente por conjunto). Devolverá una dirección booleana válida o no válida y, opcionalmente, el conjunto de reglas contra las que se validó.
La rutina de impresión nuevamente aplicará el conjunto de reglas apropiado (probablemente diferente de su conjunto de validación) a los datos de dirección para proporcionar una dirección formateada.
Espero que los otros componentes sean obvios desde el enfoque general.
Este enfoque tiene la intención de hacer frente a estos problemas identificados en su pregunta:
Partición de códigos de teléfono.
Número limitado de códigos de área posibles en uso.
Bloques de números de teléfono reservados para fines específicos.
Normalización de datos: los datos están normalizados. Sin embargo, este tipo de normalización (indexación inversa) generalmente no se usa, excepto en el software de depósito de datos y las bases de datos que contienen información masiva del sensor en tiempo real. Es posible que al implementar esta solución, usted termine eligiendo (duplicar) datos (de manera controlada). Esta no es una parte inherente de la solución, pero puede ser conveniente.
Yo recomendaría NO agregar clases para cada variante, esto no es escalable, ni puede mantenerse.
La búsqueda se detalla a continuación.
Se evitan las tablas de monstruos: es probable que la base de reglas sea o el orden de cientos a miles de reglas bajas, además de los datos reales.
La solución es escalable: una simplemente agrega o modifica las reglas.
y también hacer frente a algunos problemas relacionados.
Incluso si puede aplicar reglas de validación a formatos nacionales de direcciones, siempre habrá excepciones a las normas para un país en particular. Mi propia dirección es un ejemplo: vivo en un barco y necesito información adicional incluida en mi dirección, además de la dirección estándar de la oficina postal. Es muy probable que las anomalías de este tipo necesiten intervención manual, de ahí la regla de aceptación por intervención manual.
Los diferentes países tienen diferentes ordenamientos para las direcciones; las direcciones en China, por ejemplo, están escritas: País; Código postal; Ciudad; Zona de la ciudad; Nombre de la calle; Número de casa; Nombre de la persona
Aceptación de la primera dirección de un área donde no tiene reglas, y las reglas del país son diferentes de las que ha registrado.
Personas que desean utilizar (por ejemplo, una oficina) una dirección diferente de "su".
Preocupaciones específicas de direccionamiento individual: alguien que desee ocultar su correspondencia a sus seres queridos más cercanos.
La solución se puede extender a problemas similares, por ejemplo, referir a una persona. Esto puede implicar títulos: Dr, Rev, etc. multiplicar los nombres con guiones (ffoulkes-symthe); calificaciones (CPA, BSc, etc., y calificaciones familiares (la tercera, etc.) y múltiples modos de denominación dependiendo de la cultura de las personas (las personas del subcontinente indio a menudo no tienen un apellido, y cada uno aparentemente tendrá un apellido diferente) .)
cambios en las reglas de direccionamiento (por ejemplo, adición de un nuevo código postal para un nuevo desarrollo) se puede hacer fácil y rápidamente
problemas que aún surjan son:.
Las búsquedas serán algo más compli cated: necesita buscar todas las líneas y etiquetas de direcciones asociadas en lugar de campos de dirección específicos
Lleva tiempo crear una base de reglas de este tipo, aunque la carga de las reglas iniciales se puede realizar con bastante rapidez. Hay ejemplos presentes en su pregunta: cualquier cosa como un conjunto completo solo estará presente después de haber tratado múltiples excepciones y anomalías.
EDIT:
yo no estaba al tanto de BigTable cuando escribí mi respuesta. Después de haberlo visto muy rápido, parece ser un concepto muy similar. En cuanto a su implementación en un desarrollo ACID, creo que esto es posible para el conjunto de datos de contacto y para la base de datos de reglas.Por experiencia, sé que se puede ampliar fácilmente a 5 * 10^7 conjuntos de detalles de contacto en dicho entorno (aunque con antecedentes, validación no crítica de los datos de contacto).
Al considerar el caso de ACID/SQL mi uso de la palabra "ver" puede haber iniciado una liebre que va en una dirección que no pretendía. Una palabra más apropiada puede haber sido visión general o perspectiva (algo sin un modelo relacional o carga DBMS adjunta). De hecho, consideraría cada una de las cosas a las que me refería como una vista, como una tabla de candidatos.
Establecí un boceto de un esquema para mi enfoque para ayudar a la discusión. Este esquema usa algunas conexiones M: N, que obviamente se normalizarían en una implementación como tablas asociativas. Esto se deja como un ejercicio para el lector :-). He puesto algunos atributos de muestra y datos en algunas de las tablas.
En el dibujo, la edición del conjunto de reglas; Regla; y las reglas relacionadas con otras reglas (la aplicación administrativa) se pueden hacer obviamente con las propiedades ACID mediante operaciones CRUD normales de SQL en Usuario de dirección; Dirección; y la línea de dirección se puede hacer igualmente de manera ACID/SQL, tomando las líneas de dirección como entradas por parte del usuario. Es posible que desee realizar un preprocesamiento de la transacción para separar (en mi ejemplo) el Número de casa del Nombre de la carretera y, consecuentemente, perder la regla de "Nombre de la ruta". Otro preproceso que probablemente sea útil es la estandarización de las mayúsculas, aunque esto también podría ser parte del paso de validación. También es posible simplemente aceptar la línea completa "9 Richmond Road" como entrada, y etiquetarla como "Necesita Validación". En cualquier caso, no hay ningún problema (que yo sepa) sobre hacer esta transacción ACID.
Donde estoy menos claro es cómo la validación y el etiquetado posterior se pueden incorporar a la transacción ACID/SQL. Parece que para hacer que el paso de validación sea ACID, puede ser necesario ordenar la aplicación de la prueba en relación con los conjuntos de reglas (con los casos más comunes probados primero, y detenerse cuando la validación es exitosa). También puede ser necesario, para realizar la transacción ACID, validar solo contra su caso más común, dejando a los demás etiquetados como "Validación de necesidad", que luego se realizaría como una tarea en segundo plano.
La tarea real de validación consiste en verificar toda la base de reglas, establecida por conjunto, hasta que se encuentre un conjunto de reglas que validen todas las líneas de entrada. Obviamente, existen algunos lineamientos de los datos: si tiene un país grabado, esto le permite etiquetar la línea con el país inmediatamente y proporciona un filtro para los conjuntos de reglas contra los que debe realizar la prueba. Lo siento, pero esto es lo más lejos que puedo tomar este aspecto hasta ahora.
Dicho sea de paso, este esquema de boceto solo va en parte hacia la normalización total. Como se dibuja, cada dirección tiene su propia secuencia de líneas de dirección, y no hay normalización de los datos más allá de las líneas individuales como entrada (más o menos cualquier preproceso que elija hacer). Es posible llevar este enfoque aún más lejos: estableciendo el enlace entre la Dirección y la Línea de direcciones M: N y asegurando que el campo Línea de la tabla Línea de direcciones sea su clave principal.
Cuando se trata de recursos más detallados para este concepto, tengo dos problemas. El primero (y trivial) es que este concepto es mi trabajo original, basado en mi experiencia durante más de veinte años como consultor de métodos y consultor de Estrategia de TI con un interés especial en la tecnología del entorno de desarrollo y los métodos de desarrollo. Toda mi vida laboral se ha utilizado en entornos donde los datos de contacto han sido una gran preocupación (por razones financieras y normativas/legislativas). De hecho, mi respuesta original a tu pregunta fue completa en mi mente antes de que terminara de leer tu pregunta, aunque me llevó alrededor de tres cuartos de hora escribirla.
La razón más importante es que algunas de las fuentes de esta idea son confidenciales o secretas. En mi carrera laboral, parte de mi trabajo consistió en estar al día con los desarrollos tecnológicos y predecir el impacto de la tecnología en el negocio dentro de diez años. Esto implicó visitar laboratorios de investigación y tener discusiones con investigadores líderes sobre una variedad de temas. Aunque yo no soy un investigador de primera clase, sí soy muy bueno para sintetizar los esfuerzos de investigación de otros. Sin embargo, mientras hacía esto, siempre operaba bajo condiciones de confidencialidad comercial y/o secreto militar. Ninguna de mi respuesta ha violado estas condiciones. Como resultado de esto, solo puedo dar pautas vagas sobre cómo se obtuvo la información.
Mis fuentes son:
un seminario realizado por C J Fecha, en IBM, la exploración de los límites más lejanos de la normalización y el modelo relacional (no el modelo relacional tal como se aplica en SQL). Esto implicó la exploración de la quinta (?) Y sexta (?) Formas normales.
una serie de conversaciones con el personal técnico de Oracle durante un período de tiempo, discutiendo metadatos; meta meta datos; y otras tales generalizaciones.
discusiones con un establecimiento de investigación militar con sede en el Reino Unido. Aunque esto fue hace algunos años, no estoy seguro de si alguna vez se ha publicado algo sobre los temas que estábamos debatiendo.
trabajando en una gran institución financiera cuyo sistema de detalles de contacto se formó de forma muy parecida a mi propuesta, pero surgió de raíces no relacionales; y para los cuales el ímpetu técnico original era ahorrar espacio en una época en la que la memoria, la memoria persistente y la capacidad de respaldo eran una gran preocupación.
EDIT:
que completaron el texto de arriba, cierra mi equipo, hicieron algunas tareas de la casa, se fue a la cama, ley abajo, cerrar los ojos, y que tenía la solución a la parte No pude completar en esa edición anterior.
Si bien hay actualizaciones por hacer cuando etiquetar/validar gran parte del trabajo es en realidad la lectura y la comparación. Como tal, es un candidato principal para el bloqueo optimista. En este pseudo código se vería así:
Start read transaction
Read set of address lines where one or more lines are "Needs Validation"
Read all rule set names
Read all rule lines which belong to the first rule set
If read is not successful then abandon and start process again
End read transaction
Do while address not validated and not end of rule sets
If set of address lines validates against first rule set then
prepare transaction by allocating the tags to be applied to each line of the
address and temporarily recording the rule set that has validated the address
Start validation transaction
Read same set of address lines and rule set (all fields)
Is the address and the rule set identical to what was obtained in the read
transaction?
If identical then
create appropriate set of Tag Usage records
if successful then
commit validation transaction
end overall process
if not successful or
if not identical then
rollback validation Tag and Tag Usage
** This is the point where there might be problems if the rule set has
changed since reading it. The ordering may have changed due to amendment
deletion or creation of rule sets. This is the reason for the read of all
the read set names initially. However if there is such a change one can
afford to fail to validate and move on, aiming to come back to this address
later.
End of validation transaction
Start read transaction
Read rule lines which belong to the next rule set
End read transaction
End while loop
If end of rule sets reached and address not validated
begin create Tag Usage transaction
create tag usage pointing to Tag "Manual Intervention needed"
end create Tag Usage transaction
Los tres tipos de transacción (Dirección, actualizaciones de dirección de línea, conjunto de reglas, regla actualizaciones, y la etiqueta, actualizaciones de uso de la etiqueta) ajustarse a las condiciones ácidas. Creo firmemente (pero no lo he probado) que cualquier conjunto de entrelazado, combinación o intersección de estos tres tipos de transacción también cumplirá las condiciones ACID.
Eso es realmente un problema interesante. ¿Desea validar estos datos desde el procedimiento o activador de la tienda o desea que los clientes de BD los validen? –
Tengo la sensación de que puede ser necesaria una combinación de estos en la implementación, pero en teoría creo que los Procedimientos almacenados y los desencadenantes pueden ser la mejor opción. – Incognito