La construcción de una base de datos de contacto - ¿Necesita un poco de inspiración esquema

Question

He estado trabajando para delinear la estructura de datos para una aplicación que estoy trabajando. Una de las cosas que necesitará para manejar es el almacenamiento de la información del cliente / contacto. He estado estudiando la interfaz de unos programas de información de contacto diferentes, como libreta de direcciones, contactos de Gmail, etc.

He hervida básicamente el contacto a una "entidad" (persona, empresa, papel, etc).

• Cada Entidad puede tener múltiples Dirección , Teléfono , correo electrónico entradas.
  • Cada una de ellas define una "relación" (casa / trabajo / asistente, etc)
  • Entidad {1} - {relación} -> {0 .. *} datos
• Una 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 un empleado , cónyuge
  • Entidad {0 .. } <- {relación} -> {0 .. } Entidad

¿Alguien ha hecho ningún implementaciones SQL de bases de datos de contacto similares? Cualquier idea / sugerencias / trampas para evitar que se podría compartir con alguien que intenta trabajar en un proyecto por sí solos aquí? ¿Lo que yo he descrito parece razonable o excesivamente complicada?

Una pregunta, digamos que usted tiene 4 personas que todo el trabajo en la misma empresa. Todos ellos tienen el mismo "trabajo" número de teléfono (tal vez con una extensión diferente) - Si el número o la dirección de los cambios de "trabajo", me gustaría ser capaz de actualizar los contactos con bastante facilidad. Ahora un montón de esto se reduce a cómo utilizaría la base de datos. Estoy pensando que esto se convierte en una cuestión de la vinculación de los empleados de sus respectivas entidades de la compañía, pero entonces la dirección / número de teléfono está conectado ya no directamente al empleado. Soy una especie de debatir hacer que la relación Entidad / datos de muchos a muchos que le permite conectar la dirección / número de teléfono mismo correo a varias personas, así como su actualización en un solo lugar puede actualizarlo en todos los lugares. ¿Estoy pensando un poco más de esto? saca el pelo

Answer 1

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

Yo sugeriría mirar objeto papel de modelado (o esta también) para definir el modelo en la llanura Inglés antes de que realmente implementa ninguna tabla. Yo uso este plugin VS:. NORMA que también generará un esquema para usted también

Por otra parte, hay un montón de modelos de datos aquí que puede inspirar. Se trata de "Gestión de contactos", pero hay otros, como por ejemplo la sección "Clientes"

(Sólo quería publicar una imagen ..)
_{(fuente: databaseanswers.org )}

Answer 2

Esto es sólo para ayudar con su segunda pregunta; donde la extensión de teléfono en realidad pertenece a la relación entre la persona y de la empresa entidades.

Answer 3

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 arranque de base de datos de esquemas .

---

editar (abril de 2016): Se parece al administrador de Microsoft rompió el enlace. Aquí está la href="https://web.archive.org/web/20120419144612/http://msdn.microsoft.com/en-us/express/bb403186" rel="nofollow"> Wayback Machine Archivo de la página.

Answer 4

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 entonces, por definición, el empleador de esa persona.

¿Está considerando direcciones como entidades en sí mismas, o texto como meramente libre asociado a una persona / lugar? En algunas aplicaciones, la dirección (edificio física, etc) es 'real' y sólo puede existir en la tabla. (A menudo utilizando el / identificador postal del gobierno para ello).