Diseño de la base de datos de la libreta de direcciones: desnormalizar?

Question

Estoy diseñando una aplicación de administrador de contactos/libreta de direcciones, pero no puedo establecer el diseño de la base de datos.

En mi configuración actual, tengo un contacto, que tiene direcciones, números de teléfono, correos electrónicos y organizaciones. Todas las propiedades de contacto son actualmente tablas separadas con un fk en la tabla de contactos. No hace falta decir que un contacto puede tener cualquier cantidad de estas propiedades.

Ahora, me encuentro uniendo todas estas tablas si quiero leer contactos en la aplicación. Dado que no se realizan filtros, búsquedas inversas, ordenaciones, etc. en las tablas relacionadas, ¿no es una solución mejor/más simple almacenar simplemente los campos relacionados como listas codificadas json en propiedades directas de la tabla de contactos?

P. ej., En lugar de un contacto con un fk en una tabla de números de teléfono con 3 entradas, simplemente codifique todos los números de teléfono y guárdelos en un campo de la tabla de contactos.

¡Cualquier idea realmente apreciada! (fyi estoy usando Django aunque eso realmente no importa)

Answer 1

¿Puedes garantizar que tu aplicación nunca necesitará estas otras funcionalidades? ¿Realmente quieres pintarte en la esquina de tal manera que no puedas soportar todo esto más adelante fácilmente?

En general, la desnormalización ocurre solo por razones de rendimiento. Y luego, una copia de los datos normalizados se conserva para el trabajo en vivo y los datos desnormalizados se usan para el procesamiento fuera de línea donde está bien tener una instantánea estática.

Acostúmbrate a escribir uniones. Esa es la forma en que SQL funciona. Tener que hacerlo no significa que algo esté mal.

Answer 2

Sé que soy demasiado tarde, pero para cualquiera con el mismo problema.

IMO, en este caso el modelado de metadatos es el camino a seguir. http://searchdatamanagement.techtarget.com/feature/Data-model-patterns-A-metadata-map

Answer 3

Parece que toma datos modelados actualmente como cinco tablas SQL y las convierte a un tipo común de varios valores (¿su producto SQL tiene un buen soporte para esto?) La única forma en que puedo ver esto sería ' "desnormalización" sería si estuviera proponiendo violar 1NF, en cuyo momento también puede abandonar SQL como un almacén de datos porque sus datos ya no serían relacionales. De lo contrario, sus datos aún se normalizarían, pero habrá perdido la posibilidad de consultar sus atributos mediante SQL (a menos que su producto SQL tenga extensiones para consultar atributos de valores múltiples). El factor decisivo parece ser: ¿necesita consultar estos atributos usando SQL?