Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Bases de datos > MS SQL Server
Registrarse FAQ Miembros Calendario Guía de estilo Temas de Hoy

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 03-08-2007
jordan23 jordan23 is offline
Miembro
 
Registrado: jun 2005
Posts: 21
Poder: 0
jordan23 Va por buen camino
Dos opinionenes de Base de datos

1) Que opinan de una base de datos de la cual sus tablas no maneje llaves foraneas es decir que no haya relaciones??? que ventajas o desventajas podría tener??

2) Y un tema que ya me ha tocado debatir las Las llaves primarias de una tabla deben hacer referencia a un campo o grupo de campos??? por ejemplo CodigoArticulo o las llaves debe primarias solo debe ser un campo??? por ejemplo incremental??? IdArticulo

Agradeceré sus repuestas.
Responder Con Cita
  #2  
Antiguo 03-08-2007
Avatar de jhonny
jhonny jhonny is offline
Jhonny Suárez
 
Registrado: may 2003
Ubicación: Colombia
Posts: 7.058
Poder: 30
jhonny Va camino a la famajhonny Va camino a la fama
Mi opinion:

1) Una BD sin llaves foraneas, corre el riesgo de que tenga datos inconsistentes, como ejemplo:

Tengo una tabla de clientes y otra de movimiento de cliente, pero el dia de mañana le hicieron una factura al cliente 55555 que no existe. Me quedaria un moviemiento en la tabla MovClientes de un cliente inexistente, lo cual es una inconsistencia.

2) Eso depende de tu necesidad, en algunas tablas vas a necesitar un grupo de campos para definir la llave primaria, pero en otros casos solo necesitaras un campo para definirla.
__________________
Lecciones de mi Madre. Tema: modificación del comportamiento, "Pará de actuar como tu padre!"

http://www.purodelphi.com/
http://www.nosolodelphi.com/
Responder Con Cita
  #3  
Antiguo 03-08-2007
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
1) Una base así no vale dos cacahuates.

2) Yo prefiero usar llaves que no involucren ningún dato significativo. Hay llaves naturales, como el SSN de los gringos, el RFC mexicano o los RUTs, que podrían usarse como llaves primarias por el mero hecho de ser únicas. Pero cualquier error en la captura, dará dolores de cabeza para corregirlo, porque estará en todas las tablas que tengan ese campo como llave foránea. Luego entonces, prefiero usar llaves artificiales, y para ello basta un sólo campo, p. ej. un autoincremental.

// Saludos
Responder Con Cita
  #4  
Antiguo 03-08-2007
Avatar de mamcx
mamcx mamcx is offline
Moderador
 
Registrado: sep 2004
Ubicación: Medellín - Colombia
Posts: 3.911
Poder: 25
mamcx Tiene un aura espectacularmamcx Tiene un aura espectacularmamcx Tiene un aura espectacular
Concuerdo con roman. Usar siempre AutoIncs para las llaves... ademas se elimina la necesidad de hacer un UPDATE en cascada si se llega a cambiar (que pasa).

Un semi-desventaja es no tener el dato "a la mano" en las tablas hijas, como en el caso de un detalle de factura, pero para eso son las vistas!
__________________
El malabarista.
Responder Con Cita
  #5  
Antiguo 03-08-2007
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
Cita:
Empezado por mamcx Ver Mensaje
Un semi-desventaja es no tener el dato "a la mano" en las tablas hijas, como en el caso de un detalle de factura, pero para eso son las vistas!
Eso sí; termina uno teniendo tablas con muchos números que no nos dicen nada y puede ser bastante impráctico para revisar datos a pie, fuera del sistema. Los joins están a la orden. En algunos casos, además de las llaves artificiales, dejo los campos que en otras circunstancias habrían sido llaves foráneas, para evitar tanto join, pero sólo como referencia.

// Saludos
Responder Con Cita
  #6  
Antiguo 03-08-2007
jordan23 jordan23 is offline
Miembro
 
Registrado: jun 2005
Posts: 21
Poder: 0
jordan23 Va por buen camino
Muy interesantes sus respuestas las cuales agradezco mucho.
Responder Con Cita
  #7  
Antiguo 04-08-2007
Avatar de AzidRain
[AzidRain] AzidRain is offline
Miembro Premium
 
Registrado: sep 2005
Ubicación: Córdoba, Veracruz, México
Posts: 2.914
Poder: 21
AzidRain Va camino a la fama
Yo coincido con Roman, siempre uso claves artificiales excepto cuando hay algun campo candidato a clave única que no tenga forma de introducir errores de captura, por ejemplo: un número de factura.

Te comento que además los incrementales tienen la gran ventaja de que (al menos en MySQL y tablas MyISAM) puedes usar varios a la vez y el motor se encarga de ir creando categorias. Por ejemplo para un pedido y sus lineas, defino el pedido con una clave autoinc para la primaria y la tabla de lineas le pongo un campo "normal" que contiene la clave externa y un campo autoinc ambos como clave primaria de manera que MySQL en automático me va generando numeros de línea independientes para cada pedido.
__________________
AKA "El animalito" ||Cordobés a mucha honra||
Responder Con Cita
  #8  
Antiguo 04-08-2007
Avatar de delphi.com.ar
delphi.com.ar delphi.com.ar is offline
Federico Firenze
 
Registrado: may 2003
Ubicación: Buenos Aires, Argentina *
Posts: 5.932
Poder: 27
delphi.com.ar Va por buen camino
Cita:
Empezado por jordan23 Ver Mensaje
1) Que opinan de una base de datos de la cual sus tablas no maneje llaves foraneas es decir que no haya relaciones??? que ventajas o desventajas podría tener??
¿Que opinarías si Ford produce un automóvil nuevo solo con la tecnología de su modelo T?.... No solo se trata de evitar problemas de integridad, sino que también las cláves foráneas facilitan la comprensión del modelo de datos, asisten al optimizador al realizar consultas....


Cita:
Empezado por jordan23 Ver Mensaje
2) Y un tema que ya me ha tocado debatir las Las llaves primarias de una tabla deben hacer referencia a un campo o grupo de campos??? por ejemplo CodigoArticulo o las llaves debe primarias solo debe ser un campo??? por ejemplo incremental??? IdArticulo
El segundo punto coincido totalmente con lo expuesto por Román, y agrego que de ser necesario crees claves únicas para los campos que sepas no se repetirán.
__________________
delphi.com.ar

Dedique el tiempo suficiente para formular su pregunta si pretende que alguien dedique su tiempo en contestarla.
Responder Con Cita
  #9  
Antiguo 16-08-2007
Avatar de Neftali [Germán.Estévez]
Neftali [Germán.Estévez] Neftali [Germán.Estévez] is offline
[becario]
 
Registrado: jul 2004
Ubicación: Barcelona - España
Posts: 18.286
Poder: 10
Neftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en bruto
Cita:
Empezado por jordan23 Ver Mensaje
(1)...ventajas o desventajas podría tener??

(2)...Las llaves primarias de una tabla deben hacer referencia a un campo o grupo de campos???
(1) Ventajas, no le veo ninguna, como desventaja basta nombrar "La inconsistencia de Datos"; Para cualquiera que se preocupe un poco por los datos esa sólo frase debería ser suficiente.
(2) En algun sitio he leído que las claves autoincrementales son más eficientes (apostaría que es más, por ser numérico que por compuesta), y tiene sentido, pero realmente creo que estamos hablando de porcentajes de eficiencia muy bajos.
Yo suelo usar ID y luego lo que sería la clave compuesto con un indice único.
__________________
Germán Estévez => Web/Blog
Guía de estilo, Guía alternativa
Utiliza TAG's en tus mensajes.
Contactar con el Clubdelphi

P.D: Más tiempo dedicado a la pregunta=Mejores respuestas.
Responder Con Cita
Respuesta



Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Crear base de datos y cargar datos desde delphi Albano MySQL 4 17-05-2007 20:01:18
Herramienta case para diccionario de datos de base de datos firebird mcalmanovici Firebird e Interbase 1 11-02-2007 15:17:37
Guardar en 1 base de datos SQL, datos procedentes de 2 tablas distintas adaypr C++ Builder 1 05-09-2006 11:56:33
ubicar archivo, con datos sacados de base de datos Giniromero Varios 19 20-10-2005 16:23:02
Reto Para Expertos En Base De Datos Y Tipos De Datos.... (blob) frankmch Conexión con bases de datos 2 08-09-2003 19:44:52


La franja horaria es GMT +2. Ahora son las 10:23:56.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi