Utilice la dirección de correo electrónico como clave primaria?

Es la dirección de correo electrónico un mal candidato para la primaria cuando se compara con incrementos automáticos de números?

Nuestra aplicación web necesita la dirección de correo electrónico a ser único en el sistema. Así que, he pensado en usar la dirección de correo electrónico como clave primaria. Sin embargo, mi colega sugiere que la cadena de comparación será más lenta que la comparación de enteros.

Es una razón válida para no utilizar el correo electrónico como clave principal?

Estamos utilizando PostgreSQL.

  • ¿Qué entiende usted por ‘principal’? Si la dirección de correo electrónico debe ser única, a continuación, por lo que es clave y requiere una restricción unique. Si usted decide ‘promover’ se está ‘principal’ es arbitrario, a menos que exista una razón práctica para hacer así por ejemplo, la optimización de un mal rendimiento del sistema.
  • Si usted quiere que su base de datos para hacer cumplir una única dirección de correo electrónico, a continuación, crear una columna con un índice único, pero no usarlo como clave principal.
  • Si alguien quiere cambiar su dirección de correo electrónico? Vas a cambiar todas las claves externas demasiado?
  • Westgate: ¿cuál es la distinción entre el «índice único» y la «clave principal» que estás haciendo? Es la misma distinción que el OP está haciendo? Para mí, la diferencia entre una restricción única y una clave principal son tan sutiles que no vale la pena molestarse con.
  • casi ninguna diferencia, pero la clave principal será agrupado por defecto, mientras que un índice único no será. Usted todavía desea definir la clave principal que será el predeterminado registro único de búsqueda clave, el único índice sólo ejerce la unicidad de la columna a través de un índice normal
  • una clave principal es entoncés se utiliza para hacer referencia a entidades filiales. también puede ser que las exportaciones de niño de datos para sistemas secundarios/DB. Como un correo electrónico tiende a cambiar con el tiempo, este cambio debe ser en cascada. Como una clave principal que me gustaría usar algo menos probable el cambio de una dirección de correo electrónico
  • Westgate: FYI, no hay tal cosa como el agrupamiento automático en PostgreSQL. Una CLAVE PRINCIPAL se implementa en el disco exactamente el mismo que el de un ÍNDICE ÚNICO, donde todos los campos son NO NULOS.
  • Hmm ok. No sé acerca de postgres. Debe haber sido añadido a la pregunta. Ciertamente, en MSSQL hay un orden físico.
  • Westgate: para volver a la original del comentario: «crear una columna con un índice único, pero no usarlo como clave principal» — ¿ahora de acuerdo en que no es «apenas» base para recomendar este? Incluso en SQL Server de la tierra, donde puede definir explícitamente una tabla de índice agrupado (y tal vez está mejor hecho de esa manera), que hace que casi ninguna diferencia.
  • No, en absoluto. En Sql Server Tierra’ usted wouldnt clúster de un índice en una clave que no están usando, por ejemplo el correo electrónico. En Sql Server tierra tendría su principal ie índice agrupado en un valor entero. Usted, sin embargo, exige la unicidad de la dirección de correo electrónico mediante el uso de un índice único, además de la clave primaria. Como ya he dicho, no sé nada acerca de postgres. Espero que aclara que uno para usted.
  • Westgate: En Sql Server la Tierra se puede lograr todo lo que dijo sin usar PRIMARY KEY. Así que ¿cuál es la justificación para el uso de PRIMARY KEY a todos?
  • Clave principal tiene que ser el objetivo de una clave externa.
  • no es cierto, una clave externa puede estar vinculado a un PK o un campo que existe una restricción única en SQL Server.
  • Que es somethign I didnt know – gracias HLGEM

InformationsquelleAutor robert | 2010-09-27

25 Kommentare

  1. 277

    Comparación de cadenas es más lento que el de int comparación. Sin embargo, esto no importa si usted simplemente recuperar un usuario de la base de datos utilizando la dirección de correo electrónico. No importa si usted tiene consultas complejas con múltiples combinaciones.

    Si almacena información acerca de los usuarios en varias tablas, las claves externas a la tabla de usuarios será la dirección de correo electrónico. Eso significa que usted almacene la dirección de correo electrónico varias veces.

    • +1 por mencionar claves foráneas; ese es el principal problema
    • El problema no es que la dirección de correo electrónico se almacena en múltiples ocasiones, a pesar de que definitivamente es ineficiente, sino que se preocupa de espacio en el disco duro día de hoy. La mayoría de las empresas no tienen google escala, cuando ello importa. El problema es que la dirección de correo electrónico no puede ser cambiado después, porque es una clave principal & hace referencia como clave externa.
    • ¿Quién dijo algo acerca de espacio en el disco duro? Cualquier cosa que tienda se va a ocupar espacio en la memoria RAM.
    • En cualquier caso, uno se pregunta, como yo, un GUID clave sería equivalente a una tecla de correo electrónico, creo.
  2. 175

    Yo también señalar que el correo electrónico es una mala opción para hacer un campo único, hay personas e incluso las pequeñas empresas que comparten una dirección de correo electrónico. Y como los números de teléfono, los correos electrónicos pueden ser re-utilizados. [email protected] puede fácilmente pertenece a John Smith, un año y Julia Smith, dos años más tarde.

    Otro problema con los correos electrónicos es que cambian con frecuencia. Si usted se une a otras tablas, como la clave, entonces usted tendrá que actualizar las otras mesas, así que puede ser un buen rendimiento cuando un cliente completo de la empresa los cambios de sus mensajes de correo electrónico (que he visto que sucede.)

    • +1 por mencionar la actualización en cascada problema. Es por eso que los amigos dejan que sus amigos sólo el uso de claves de suplente ;-).
    • Me encanta la frase:»es por eso Que los amigos dejan que sus amigos sólo el uso de claves de suplente
    • ah, no me gusta el dicho… todo el sustituto de las claves también puede ser el origen de problemas; sí, la aplicación será más robusto a cambios de negocio y/o reglas de integridad, sin embargo, la información puede perderse un poco más fácil y la identidad de los registros es menos clara. así que yo no se recomienda una regla de pulgar aquí…
    • Nunca en los 30 años de la base de datos de trabajo registros perdidos debido a un sustituto clave.
    • El OP dice muy claramente: «Nuestra aplicación web necesita la dirección de correo electrónico a ser único en el sistema» por lo que su observación acerca de «la gente y… empresas que comparten una dirección de correo electrónico» no se aplican en este caso.
    • Cómo podría la gente comparte una dirección de correo electrónico? Si las direcciones de correo electrónico no son únicos, todo el sistema de correo electrónico se rompe. A menos que usted quiere decir que, por ejemplo, un esposo y esposa pueden compartir una única cuenta de correo electrónico. Pero en ese caso, son realmente dos diferentes clientes? Ahora depende de lo que su definición de «cliente» es. He usado las direcciones de correo electrónico como claves primarias y nunca tuve un problema con eso. Tal vez en algunos casos no sería un problema. Tienen que mirar el contexto.
    • y @jay, sólo porque usted piensa que debería ser único doen’t la hacen única. Y sí, el esposo y la esposa pueden ser diferentes de los clientes. Sólo porque usted no ha ejecutar en esto antes no quiere decir que no va a suceder. He corrido en ella, y sucede que es la razón por correo electrónico nunca se debe permitir que para ser considerado único si usted piensa que debería ser o no. Este es el tipo de requisito que empujar porque es intrínsecamente malo.
    • No quiero entrar en una interminable discusión, pero no se puede decir que la propuesta de una clave no es el único basado en casos hipotéticos sin conocer el contexto. por ejemplo, de la compañía de teléfono del punto de vista, un número de teléfono identifica únicamente a un cliente, por definición. Sí, usted puede decir, «Pero lo que si hay dos o tres personas que podrían responder al llamar a ese número?» Pero esto es irrelevante. De la compañía de teléfono del punto de vista, por definición, este es uno de los clientes. (continuación …)
    • (continuación) Asimismo, si usted está construyendo un sistema que es en gran parte de que se trate con las comunicaciones por correo electrónico, quizá de envío de mensajes del sistema, o una notificación del sistema de la expedición -, entonces es probable que, por definición, una dirección de correo electrónico identifica de forma única a un usuario. Si varias personas comparten esa dirección de correo electrónico, que es irrelevante. Ellos son un solo mensaje de destino, por lo tanto, son un único usuario. «Usuario» y «cliente» no tiene que ser sinónimo de «ser humano individual».
    • Más probable es que la dirección de correo electrónico va a ser utilizado como un IDENTIFICADOR de inicio de sesión. Que podrían incomodar a 1% de los clientes, pero el otro 99% será mucho más feliz la experiencia relativa al tener que elegir y recordar un nombre de usuario único. La única otra alternativa es OpenID que la mayoría de los laicos no tienen.
    • Muchos de los sitios web que frecuentan requieren que proporcione una única dirección de correo electrónico para identificar mí: Amazon, Google, Microsoft, etc. Indique cómo puedo «push back» este requisito a ellos.
    • … aunque no estoy seguro de que quiero: supongo que, como yo, como la idea de que una dirección de correo electrónico es verificable (que requieren que responder a un correo electrónico que envíe) y familiar para los usuarios (es decir, puedo recordar mi propia dirección de correo electrónico!), ambos de los cuales son las propiedades de una buena clave.
    • también para agregar…la gente macho ERROR tipográfico errores a la hora de crear cuentas en línea…esto también hará pesadilla para usted para cambiar la dirección de correo electrónico en todo los lugares.

  3. 97

    la clave principal debe ser único y constante

    direcciones de correo electrónico cambia como las estaciones del año. Útil como una clave secundaria para la búsqueda, pero una mala elección de la clave principal.

    • Una propiedad de una buena clave es que se debe ser estable, pero NO necesariamente inmutable.
    • Yep! De lo contrario, ¿por qué habría de SQL soporte de actualizaciones en cascada?
    • si usted tiene una opción, vaya constante/inmutable claves; menos trabajo para usted por el camino, simplemente porque SQL admite actualizaciones en cascada no quiere decir que siempre es una buena idea!
    • «cambia como las estaciones del año»… me acabo de hacer con un proyecto donde los usuarios’ los e-mails cambian con frecuencia, y sin ningún aviso previo a la aplicación de los administradores o desarrolladores.
    • +1: depender de las actualizaciones en cascada es una mala práctica (se frenos db normalización)
    • Malgrat: «actualizaciones en cascada… frenos db normalización» — a mi entender se ha entendido mal el concepto de normalización!
    • en una normalizado en db, usted no debe tener la misma información repetida en varias filas. Una dirección de correo electrónico como clave principal se repite en todas las claves externas.
    • Malgrat: gracias por la confirmación de que usted ha entendido mal el concepto de normalización. «usted no debe tener la misma información repetida en varias filas» … ¿realmente quiere decir «información»?! Una clave compuesta, en general implica valores repetidos en varias filas. Para una clave externa, los valores se hace referencia en lugar de «repetidos», gran diferencia. De una sola columna de dominio con dos valores (por ejemplo, ‘Sí’ y ‘No’) se tienen los mismos valores en varias filas en una tabla de referencia, si tiene tres o más filas. Esto es realmente lo básico!
    • SQL soporta actualizaciones en cascada, porque a veces la gente a romper las reglas y a las personas que limpiar después de ellos la necesidad de soluciones.

  4. 63

    Desventajas de utilizar una dirección de correo electrónico como una clave principal:

    1. Más lento al hacer combinaciones.

    2. Cualquier otro registro con el desplazamiento de clave externa ahora tiene un valor mayor, ocupando más espacio en disco. (Teniendo en cuenta el costo de espacio en disco hoy en día, esto es probablemente un asunto trivial, excepto en la medida en que el expediente que ahora se toma más tiempo para leer. Ver #1.)

    3. Una dirección de correo electrónico podría cambiar, lo que obliga a todos los registros usando esto como una clave externa para ser actualizado. Como dirección de correo electrónico no cambian a menudo, el problema de rendimiento es probablemente menor. El problema más grande es que usted tiene que asegurarse de proveer para ella. Si tienes que escribir el código, esto es más trabajo y se introduce la posibilidad de errores. Si su motor de base de datos soporta «on update cascade», es un tema menor.

    Ventajas de utilizar la dirección de correo electrónico como una clave principal:

    1. Usted puede ser capaz de eliminar completamente algunas combinaciones. Si todo lo que usted necesita desde el «registro maestro» es la dirección de correo electrónico, luego con un resumen integer clave de lo que tendría que hacer una combinación para recuperarlo. Si la clave es la dirección de correo electrónico, entonces usted ya la tiene y la combinación es innecesario. Si esto le ayuda a cualquier depende de la frecuencia de esta situación.

    2. Cuando usted está haciendo las consultas ad hoc, es fácil para un ser humano para ver qué registro maestro es la que hace referencia. Esto puede ser una gran ayuda cuando se esta tratando de rastrear los datos de los problemas.

    3. Casi seguro que tendrá un índice en la dirección de correo electrónico de todos modos, para lo que es la clave principal elimina un índice, mejorando así el rendimiento de las inserciones, ya que sólo un índice para actualizar en lugar de dos.

    En mi humilde opinión, no es un slam-dunk de cualquier manera. Tiendo a preferir el uso de claves naturales cuando un práctico está disponible porque son más fáciles de trabajar, y las desventajas tienden a no me importa demasiado en la mayoría de los casos.

    • +1 para señalar que mutable hace referencia a las claves son una PITA
    • Aunque, se pone de relieve que no es un pan de PITA si usted tiene un motor que soporta ON UPDATE CASCADE. No es un problema en ese punto de código sabio; el único problema real es cómo de extensa es la actualización y cuán amplia es la clave. Dirección de correo electrónico puede ser un poco mucho, pero una CASCADA de ACTUALIZACIÓN para un PK de 2 caracteres de código de país no es un gran negocio.
    • En mi humilde opinión, sigue siendo un pan de PITA. Por ejemplo, supongamos que cuando usted ha diseñado su país de mesa sólo había dos mesas que se hace referencia, no biggy, Pero con el tiempo se convirtió en 20 mesas cada una con cientos de miles de registros. Algunos con la referencia a algunos de los sin. Esto hace que una sola lógica escribir terminan siendo decenas de miles de escrituras, y no lo hace para todas las tablas porque alguien se olvidó de referencia cuando el añadido de la tabla. Esto es exactamente lo que me pasó en un 2 char código de país de la tabla no estoy bromeando.
    • Conrad: El peor caso es cuando no hay en la base de datos de apoyo. Entonces usted tiene que escribir código para cada mesa con un enviado de referencia, y esto es sólo un dolor y una puerta de errores a deslizar. Con las cascadas, usted sólo tiene que recordar que añadir una cláusula en cada mesa, no gran cosa.
    • Ventaja 1 y 3 son prematuros optimizaciones, ventaja 2 es un beneficio menor y es completamente superada por ninguna decente herramienta de consulta.
    • Te una diferencia entre «optimizatin» y «optimización prematura». Pero bueno, por el mismo razonamiento, todas las desventajas he visto a nadie mencionar son prematuros optimizaciones. Así que, ¿dónde deja esto a usted? En cuanto a #2, me encuentro escribiendo en extra se une al intentar hacer consultas ad hoc para ser un gran dolor de cabeza. Los registros suelen tener varias claves externas de modo que usted puede necesitar varias combinaciones para llegar a comprensibles los datos. Si por «decente herramienta de consulta» te refieres a una que calcula los datos que desea ver sin que indica y por arte de magia hace que la une para usted, me gustaría ver cómo funciona.

  5. 12

    Es bastante malo. Asumir algún proveedor de correo electrónico sale de negocio. Los usuarios, a continuación, desea cambiar su dirección de e-mail. Si usted ha utilizado el correo electrónico como clave principal, todas las claves para los usuarios duplicados de que el e-mail, por lo que es bastante maldito duro a cambio …

    … y ni siquiera he comenzado a hablar acerca de consideraciones de rendimiento.

    • ¿Cómo cambiar las direcciones de correo electrónico porque hay que ser duplicados? A menos que Un usuario cambia su dirección de correo electrónico y, a continuación, el usuario B de los cambios de su correo electrónico para ser el mismo como usuario de Un antiguo valor, y sus actualizaciones no se realizan en secuencia. Remotamente posible, supongo.
    • Una clave externa de referencia, por definición, contiene el valor de la clave primaria de la fila a la que se refiere. Dicho de otra manera, se duplica el valor de la clave primaria. (Así la duplicación no es causado por un cambio en el valor. Pero el cambio es más difícil debido a esta duplicación, y la restricción de su aplicación).
    • +1 para la línea «Asumir algún proveedor de correo electrónico que sale de la empresa».
    • Esto no es un problema. Clave externa en cascada existe para resolver este problema. Si un usuario cambia su correo electrónico, el cambio se transmitirá a todas las tablas utilizando como clave externa.
    • Os aseguro que si utiliza las actualizaciones en cascada y un proveedor fuera de la empresa o los cambios de su nombre (Yahoo.com se convierte en HooYa.com), su base de datos será bloqueado para todos los usuarios durante horas y tal vez días, mientras este en cascada a través del sistema. Es una muy válida problema (y una razón de por qué es una mala idea utilizar las actualizaciones en cascada si usted tiene cualquier cantidad significativa de datos y la clave es probable que el cambio).
    • como con todo, depende del tamaño. Si estás en facebook, se puede ir muy mal. Si sólo tiene unos pocos miles de usuarios, es probablemente «OK»‘ish… también depende de cómo muchas otras tablas. Y también hay que considerar la frecuencia con la gran de los proveedores de correo desaparecer. Los pequeños proveedores pueden venir&go, pero son pequeñas, por lo que no puede tener un millón de filas con sus correos electrónicos. Yo no uso los correos electrónicos como PK yo, sin embargo, pero no por el miedo de los proveedores de correo va a desaparecer.
    • Estoy senstitve a la cuestión, porque nuestros clientes están en una industria donde hay frecuentes fusiones y tenemos un gran número de correos electrónicos que cambia con mucha frecuencia. No se diseño para las cosas que pueden ser, normalmente, se espera que ocurra en la vida de los datos es irresponsable. Usted tiene que considerar cómo los datos serán mantenidos en el tiempo cuando la base de datos para las decisiones de diseño. Esto no prematuro de la optimización, este es el responsable de diseño.
    • Muy tarde seguimiento: estoy en apuros a pensar en la última vez que todos los x.com las direcciones de correo electrónico que fue cambiado a y.com. ¿Cómo iban a hacerlo? Si, por ejemplo, de Google fueron para la compra de Yahoo, que no podía declarar que todas las direcciones de correo electrónico de Yahoo tendrá el mismo valor de antes de la»@», pero después de la «@» ahora será «gmail.com», porque eso sería crear duplicados. Y, en cualquier caso, probablemente le acaba de pagar una pequeña cuota para mantener el antiguo nombre de dominio. Sí, los pequeños proveedores de salir de los negocios y simplemente desaparecen. Pero de cualquier manera, los cambios van a venir en uno por uno, no como algunos enormes a granel de cambio. …
    • … Si usted tiene miles o millones de registros mediante cualquier dirección de correo electrónico como una clave externa, es decir, muchos registros secundarios para cada uno de los padres de registro, o peor aún, muchos de los registros de propagación a través de muchas tablas, una cascada puede tomar una cantidad de tiempo inaceptable. Que es sin duda un factor a tener en cuenta a la hora de diseñar una base de datos. Yo creo que sería un caso relativamente raro, aunque.

  6. 12

    Yo no sé si eso podría ser un problema en la configuración, pero dependiendo de su RDBMS los valores de las columnas podrían ser caso sensibles. PostgreSQL docs decir: «Si se declara una columna como UNIQUE o PRIMARY KEY, implícitamente genera índice es sensible a mayúsculas». En otras palabras, si usted aceptar la entrada del usuario para una búsqueda en una tabla con el correo electrónico como clave primaria, y el usuario proporciona «[email protected]» usted no encontrará «[email protected]».

    • Vale la pena mencionar en este sentido que [email protected] y [email protected] puede ser el mismo buzón de correo o pueden ser diferentes buzones de correo y que no tienen forma de saber – no hay nada en la especificación para decir si la parte local es sensible a mayúsculas.
    • Tienes razón, eso depende del servidor de correo.
    • Esto es más un problema general con el singularidad la ejecución de direcciones de correo electrónico en lugar de si deben ser utilizadas como claves primarias – el mismo problema es allí cualquier manera. +1 porque es todavía muy útil punto de
  7. 11

    Nadie parece haber mencionado un posible problema de que las direcciones de correo electrónico podría ser considerada privada. Si la dirección de correo electrónico es la clave principal, una página de perfil de URL más probable es que será algo parecido a ..../Users/[email protected]. ¿Qué pasa si usted no quiere exponer a la dirección de correo del usuario? Usted tendría que encontrar alguna otra manera de identificar al usuario, posiblemente por un valor entero único para hacer URLs como ..../Users/1. A continuación, se acabaría con un valor entero único, después de todo.

  8. 9

    A la lógico nivel, el correo electrónico es la clave natural.
    En el física nivel, dado que usted está utilizando una base de datos relacional, la clave natural no encaja bien como la clave principal. La razón es, principalmente, el rendimiento de los problemas mencionados por los demás.

    Por esa razón, el diseño puede ser adaptado. La clave natural se convierte en el clave alternativa (ÚNICO, NO NULO), y utiliza un sustituto artificial//clave de técnicos de como los de clave principal, que puede ser un incremento automático en su caso.

    systempuntoout preguntó,

    Lo que si alguien quiere cambiar su dirección de correo electrónico? Vas a cambiar todas las claves externas demasiado?

    Que es lo que cascada es para.

    Otra razón para utilizar un numérico de la clave suplente como la clave principal está relacionada con la forma de la indexación de las obras en su plataforma. En MySQL InnoDB, por ejemplo, todos los índices de una tabla de la clave primaria de la pre-pendiente de ellos, por lo que el PK a ser tan pequeño como sea posible (para la velocidad y el tamaño de la causa). También relacionado con esto, InnoDB es más rápido cuando la clave principal se almacena en la secuencia, y una cadena que no ayuda allí.

    Otra cosa a tener en consideración cuando se utiliza una cadena como una alternativa a la clave, es que utilizando un hash de la cadena que desea puede ser más rápido, saltar cosas como superior e inferior de los casos de algunas letras. (De hecho, me llegaron aquí, mientras busca una referencia para confirmar lo que acabo de decir; sigue buscando…)

  9. 4

    sí, es mejor si se utiliza un entero en lugar. también puede configurar el correo electrónico de la columna como una restricción unique.

    como este:

    CREATE TABLE myTable(
        id integer primary key,
        email text UNIQUE
    );
    • ¿Por qué es «mejor»? Alguna de las razones o fuentes?
    • la experiencia y el sentido 🙂
    • ¿Puede explicar eso?
  10. 4

    Sí, es una mala clave principal ya que sus usuarios se desea actualizar sus direcciones de correo electrónico.

    • Pensé en señalar que ahora tenemos cascada este no es un problema
  11. 3

    Otra razón de por qué integer primary key es mejor cuando se hace referencia a la dirección de correo electrónico en la tabla diferente. Si la dirección en sí es una clave principal, a continuación, en otra mesa se tiene que utilizar como clave. Para almacenar las direcciones de correo electrónico de tiempo múltiples.

  12. 3

    No estoy demasiado familiarizado con postgres. Las Claves principales es un gran tema. He visto algunas de las excelentes preguntas y respuestas en este sitio (stackoverflow.com).

    Creo que se puede tener un mejor rendimiento por tener una numérico de la clave primaria y el uso de un ÍNDICE ÚNICO en la columna de correo electrónico. Correos electrónicos tienden a variar en longitud y puede no ser adecuado para el índice de clave principal.

    leyendo aquí y aquí.

  13. 3

    Personalmente, yo no uso ninguna información de la clave primaria a la hora de diseñar la base de datos, porque es muy probable que necesito para alterar cualquier información más adelante. La única razón por la que me proporcione la clave primaria es, es la conveniencia de realizar la mayoría de operación de SQL desde el lado del cliente, y mi elección para la que ha sido siempre de incremento automático de tipo entero.

  14. 2

    Su compañero de la derecha: el Uso de un autoincrementing entero por su clave primaria.

    Puede implementar el e-mail singularidad, ya sea en el nivel de aplicación, o que podrían marcar su dirección de correo electrónico de la columna como único, y añadir un índice en la columna.

    Agregar el campo como único coste de la cadena de comparación sólo a la hora de insertar en la tabla, y no cuando la realización de las uniones y la restricción de clave externa de cheques.

    Por supuesto, hay que tener en cuenta que la adición de ningún tipo de limitaciones para su aplicación en el nivel de base de datos puede hacer que su aplicación sea inflexible. Siempre dan la debida consideración antes de hacer cualquier campo «único» o «not null», sólo porque las necesidades de su aplicación a ser único o no vacía.

    • «Siempre dan la debida consideración antes de aplicar el requisito de x sólo porque sus necesidades de aplicación el requisito de x». el peor consejo que he leído en bastante tiempo.
    • No estoy convencido de que su «argumento» — en la vida real, a menudo, habrá situaciones en las que parte esencial de los datos (e.g, un número de teléfono) no estará disponible inmediatamente. Si este campo está marcado como NO NULOS en una base de datos, se requerirá a los usuarios a contaminar los datos con los campos ficticios (como 123) en lugar de dejarlo vacío. Sería más práctico para permitir que la aplicación de la manija de las restricciones (y en este caso, la aplicación podría marcar un campo vacío como un elemento de acción).
    • Estoy de acuerdo en que la definición de un campo de «not null» debe hacerse con cautela. Requisitos como «siempre necesitamos el número telefónico del cliente» debe ser considerada cuidadosamente. Podría no ser deseable a veces a crear un registro de cliente aunque no sabemos el número de teléfono ahora mismo, y volver a ella más adelante? Pero «este campo debe ser único» es una categoría diferente. No me los imagino diciendo: «está bien Que dos de los empleados que tienen el mismo número de la seguridad social, lo vamos a averiguar más tarde.» ¿Cómo podría alguna vez enderezar los datos?
    • Ser Lobos: yo conocí a una mujer una vez que no tienen su propio número de teléfono. ¿Qué hacer entonces?
    • Suena como que usted debe trabajar más, o tal vez de adaptar una actitud más amigable.
  15. 2

    Usar un GUID como una clave principal… que manera se puede generar a partir de su programa al hacer un INSERT y no es necesario para obtener una respuesta del servidor para averiguar cuál es la clave principal. También será único a través de tablas y bases de datos y usted no tiene que preocuparse acerca de lo que sucede si usted truncar la tabla y el incremento automático se restablece a 1.

    • A menos que usted se preocupa poco o nada sobre el rendimiento, a continuación, utilizar un GUID. No-no #1 si usted está construyendo un sistema que necesitará escala
    • no… ver davybrion.com/blog/2009/05/…
    • Dijo que en la verdadera Microsoft-Kool-Aid-la bebida de moda!
  16. 2

    Sé que esto es un poco de un retraso en la entrada, pero me gustaría añadir que la gente abandona las cuentas de correo electrónico y proveedores de servicios de recuperar la dirección de permitir que otra persona la utilice.

    Como @HLGEM señaló «[email protected] puede fácilmente pertenece a John Smith, un año y Julia Smith, dos años más tarde». en este caso se debe John Smith quiere que su servicio tiene que rechazar el uso de su dirección de correo electrónico o borrar todos los registros relativos a Julia Smith.

    Si usted tiene que eliminar registros y se refieren a la historia financiera de la empresa dependiendo de la legislación local, usted podría encontrar en el agua caliente.

    Así que nunca iba a utilizar los datos como direcciones de correo electrónico, número de placas, etc. como una de las principales claves porque no importa cómo el único que parece que están fuera de su control y puede proporcionar algunos desafíos interesantes que usted puede no haber tiempo para lidiar con.

  17. 1

    usted debe utilizar un número entero de clave principal. si usted necesita el correo electrónico de la columna a ser único, ¿por qué no simplemente establecer un único índice en la columna?

  18. 1

    Si usted no tiene una int valor de la clave principal, a continuación, las inserciones y las recuperaciones va a ser muy lento en datos de gran tamaño.

    • No, inserta será más lento, porque se necesita dos único índices: uno en el generado clave principal y otra en la dirección de correo electrónico.
  19. 1

    clave principal debe ser elegido un atributo estático. Desde las direcciones de correo electrónico no son estáticos y pueden ser compartidos por varios candidatos, por lo que no es una buena idea para usar como clave principal. Por otra parte las direcciones de correo electrónico son cadenas generalmente de una longitud determinada, que puede ser mayor que la única identificación que le gustaría usar[len(email_address)>len(unique_id)] por lo que requeriría más espacio y peor aun, que se almacenan en múltiples ocasiones como clave externa. Y, en consecuencia, se llevará a degradar el rendimiento.

  20. 1

    Usted puede necesitar considerar aplicable la regulación de los datos de la legislación. El correo electrónico es información personal, y si los usuarios son los ciudadanos de la UE, por ejemplo, a continuación, en virtud de GDPR puedan instruir a eliminar su información de sus registros (recuerda que esto se aplica independientemente de que el país en el que está basado).

    Si usted necesita para mantener el registro en la base de datos para la integridad referencial o razones históricas, tales como la auditoría, el uso de un sustituto de la clave que le permitirá simplemente NULOS todos los datos de carácter personal de campo. Obviamente, esto no es tan fácil si sus datos de carácter personal es la clave principal

  21. 0

    Depende de la tabla. Si las filas de la tabla representan las direcciones de correo electrónico, a continuación, el correo electrónico es la mejor IDENTIFICACIÓN. Si no, entonces el correo electrónico no es una buena ID.

  22. 0

    Si es simplemente una cuestión de exigir que el correo electrónico sea único, a continuación, sólo se puede crear un índice único con esa columna.

  23. 0

    De correo electrónico es un buen índice único candidato, pero no para los de clave principal, si se trata de una clave principal, usted no será capaz de cambiar el contacto de la dirección email por ejemplo.
    Yo creo que tu unirse a consultas será más lento también.

  24. 0

    no use la dirección de correo electrónico como clave primaria , guardar el correo electrónico como único pero, no, no uso como clave principal, utilice el id de usuario o nombre de usuario como clave primaria de la

Kommentieren Sie den Artikel

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein

Pruebas en línea