2009-12-02 17 views
12

He estado trabajando en el diseño de la estructura de datos para una aplicación en la que estoy trabajando. Una de las cosas que deberá manejar es almacenar información de contacto/cliente. He estado estudiando la interfaz de algunos programas de información de contacto diferentes, como la libreta de direcciones, los contactos de gmail, etc.Creando una base de datos de contacto - Necesita un poco de inspiración de esquema

Básicamente, he reducido el contacto a una "entidad" (individuo, empresa, función, etc.).

  • Cada Entidad puede tener múltiples Dirección, Teléfono, E-Mail entradas.
    • Cada uno de ellos define una "relación" (casa/trabajo/asistente, etc)
    • Entidad {1} - {relación} -> {0 .. *} datos
  • Un Entidad puede tener múltiples campos que son el almacenamiento de datos de forma libre para otros datos "genéricos" (cumpleaños, AIM cuenta, etc.)
    • Entidad {1} - {fieldName} -> {0 .. *} Campo de datos
  • Un Entidad puede enlazar a otro Entidad por ejemplo como empleado , cónyuge
    • Entidad {0} .. < - {relación} -> {0 ..} Entidad

Alguien ha hecho ningún implementaciones SQL de bases de datos de contacto similares? ¿Alguna idea/sugerencia/error para evitar que puedas compartir con alguien que intente trabajar en un proyecto por sí mismo aquí? ¿Lo que describí parece razonable o demasiado complicado?

Una pregunta, supongamos que tiene 4 personas que trabajan para la misma empresa. Todos tienen el mismo número de teléfono de "trabajo" (quizás con una extensión diferente): si cambia el número o la dirección de "trabajo", me gustaría poder actualizar los contactos con bastante facilidad. Ahora, gran parte de esto se reduce a cómo usarías la base de datos. Estoy pensando que esto se convierte en una cuestión de vincular empleados a sus respectivas entidades de la empresa, pero luego la dirección/número de teléfono ya no está conectado directamente con el empleado. Estoy debatiendo acerca de hacer la relación Entidad/datos de muchas a muchas, lo que le permite adjuntar la misma dirección postal/número de teléfono a varias personas, y actualizarla en un solo lugar puede actualizarla en todos los lugares. ¿Acabo de pensar esto? saca cabello

Respuesta

14

Es un poco trillado, pero necesita conocer sus datos y lo que va a hacer con él antes de empezar a pensar en las tablas.

Sugeriría mirar Object Role Modeling (o this también) para definir el modelo en inglés simple antes de implementar realmente cualquier tabla. Yo uso este complemento VS: NORMA que también generará un esquema para ti también.

Alternativamente, hay un montón de data models here que pueden inspirarte. Esto es "Gestión de contactos" pero hay otros, como por ejemplo la sección "Clientes"

(Sólo quería publicar una imagen ..) Contact Management http://www.databaseanswers.org/data_models/contact_management/images/contact_management_model.gif

+0

Gran seguimiento de recursos con el enlace –

+1

Gracias por los enlaces, definitivamente algunos útiles aquí. El diseño en esa imagen se parece mucho a lo que comencé a pensar con la relación muchos/muchos 'Customer_Addresses' ... También estoy pensando que esto podría complicar demasiado el mantenimiento de actualizar/ingresar información. ES DECIR. ¿Cómo se selecciona la "misma dirección" como otro contacto frente a la duplicación de la dirección en la tabla. – gnarf

+0

@gnarf: No he usado ni analizado este modelo, lo siento. Solo sé que el sitio – gbn

1

Un par de puntos que tienden a surgir en mi experiencia ..

Considere las relaciones recíprocas. Por ejemplo, si alguien se define como un empleado de una empresa, entonces la empresa es, por definición, el empleador de esa persona.

¿Está considerando las direcciones como entidades en sí mismas, o simplemente como texto libre asociado a una persona/lugar? En algunas aplicaciones, la dirección (construcción física, etc.) es 'real' y solo uno puede existir en la tabla. (A menudo usando el identificador gubernamental/postal para ello).

+0

Sí - Las relaciones recíprocas ya estaban en proceso, estaba pensando que podría definir ** A ** es un * empleado de * ** B ** y, por lo tanto, ** B ** tiene * empleado * ** A ** también - Sí, las direcciones van a ser su propia mesa intencionalmente, estoy tratando de reducir las posibilidades de tener información de dirección duplicada en la mesa haciendo que sea potencialmente una relación de muchos a muchos. Lo mismo con los números de teléfono .. Me gustaría para saber si bob tiene el mismo # que joe ... – gnarf

4

Esto es solo para ayudar con su segunda pregunta; donde la extensión del teléfono en realidad pertenece a la relación entre la persona y las entidades de la compañía.

contact_model_01

+0

Gracias, tiene sentido que las extensiones formen parte de la "relación" entre una persona y un teléfono. – gnarf

+0

Por curiosidad: ¿de dónde vino esa imagen? – gnarf

+0

@gnarf; yo uso Visio pro. –

2

Microsoft ofrece una serie de bases de datos de arranque esquemas, incluidos los activos de mantenimiento, gestión de contactos, clientes y pedidos, gestión de documentos, e-Commerce, Atención al cliente, número de software de seguimiento, control de inventario al por menor, y catálogos de productos. Ver Starter Database Schemas.


EDITAR (abril de 2016): Se parece al administrador de Microsoft rompió el enlace. Aquí está el Wayback Machine archive de la página.

+1

Ese enlace está muerto. –

+0

@Henry. Parece que el Webmaster de Microsoft rompió el enlace.Probablemente deberías contactar a Microsoft en [email protected], y pedirles que lo arreglen. La dirección de correo electrónico se proporcionó en la página de la Base de datos de inicio como punto de contacto. Pero no me sorprendería si el Microsoft Postmaster rompiera esa dirección de correo electrónico también. – jww

Cuestiones relacionadas