|
|
 |
 |
|
FTP | |
|
CCD | |
|
Buscar | |
|
Trucos | |
|
Trabajo | |
|
Foros | |
|
#1
13-01-2004
|
|||
|
|||
Tipo de datos
Hola!:
Feliz año retrasado a tod@s!!!. Mi problema es que tenía una tabla en Paradox con un campo descripción de 255 caracteres, que yo lo ponía como de tipo alpha, pero ahora resulta que no me llegan esos caracteres que tiene que tener por lo menos 300 o 400 y además ese campo es clave. ¿de qué tipo de datos lo puedo poner? Es que siendo Parados con el database desktop me pone k el memo no puede ser clave y además creo k tampoco ocupaba tanto y el formated memo igual. ¿Me podéis dar una solución?  El programa es para Delphi.Muchas gracias por adelantado y por favor contestad rápido, aunk si tardais tampoco pasa nada por supuesto, sólo faltaría también  .
__________________
Letty http://usuarios.lycos.es/buffangel 
|
|
#2
13-01-2004
|
|||
|
|||
|
No entiendo del todo tu inquietud, sin embargo no me parece algo corriente utilizar un campo memo o varchar como campo clave de una tabla, salvo que sea una ocación peculiar.
Si reformulás un poco tu pregunta en una de esas te podamos ayudar.
__________________
Suerte .: Gydba :.
|
|
#3
13-01-2004
|
|||
|
|||
|
A ver, resulta que tengo una tabla de facturas y luego otra que es detalles de facturas. En los detalles va la descripcion de la factura, el codigo y el importe. Y la clave es el codigo de factura+descripcion. Ej:
factura1,plano topográfico,5€ factura1,fotocopias,1€ factura1,averías,20€ factura2,plano,5€ etc. entiendes? por eso necesito un tipo de datos que coja caracteres y números porque en la mayoría de casos la descripción va a cojer letras y normalmente van a ser más palabras tipo: un plano topográfico que medía 10cm y cuya base era de 5cm por 5cm2 bla bla bla bla.... espero que ahora si me podais ayudar. Necesito saber qué tipo de datos defino al definir la estructura de la tabla.
__________________
Letty http://usuarios.lycos.es/buffangel
|
|
#4
13-01-2004
|
||||
|
||||
|
Cita:
Pero, si me permites decirlo, el diseño que estás usando es incorrecto. Los campos alfanuméricos no son convenientes para ser campos llaves mucho menos si son tan extensos como dices. Toma en cuenta que los campos llaves se usan para relacionar tablas lo que implica que las consultas deben comparar la llave primaria de una tabla con la llave foránea en la otra por cada registro. Si son muchos registros, la comparación de dos cadenas de texto es muy lenta. En tu caso te conviene usar una llave primaria numérica en la tabla de facturas y usar ésta como llave foránea en la tabla de detalles. La tabla de detalles puede tener además su llave primaria "artificial" con un campo autoinc. Quizá algo así: Facturas = (codigo, otros campos) Detalles = (Id, Codigo, Descripcion, Importe) donde Id es autoinc. Las dos tablas se relacionarían mediante el campo Codigo. De esta manera el campo Descripcion no tiee que formar parte de la llave primaria y puedes ponerlo como un campo memo. // Saludos
|
|
#5
13-01-2004
|
|||
|
|||
|
Ma apunto a lo que comenta el amigo Román, pero con una pequeña diferencia (sino, de qué la respuesta
 )La estructura de tus tablas yo las haría así (más o menos): Facturas = (codigo, otros campos) Detalles = (Codigo, Linea, Descripcion, Importe) Donde Linea sería un contador de las lineas de una determinada factura, es decir, algo así (siguiendo tu ejemplo): factura1, 1, plano topográfico,5€ factura1, 2, fotocopias,1€ factura1, 3, averías,20€ factura2, 1, plano,5€ etc. O bien otra alternativa, si las descripciones se soliesen repetir, es crear una tabla de "descripciones", "artículos", ... llamalo como quieras, que tenga (al menos) 2 campos : ID, Descripcion y hacer la unión entre las 2 tablas para saber la descripción (en el detalle de faturas sólo grabarias el ID del articulo/descripcion) Se que quizás estas propuestas hagan cambiar bastante tu diseño, pero, al igual que Román, creo es el acertado y, a la larga, seguro que te ahorran dolores de cabeza 
|
 |
|
|
 |
|
Mode Lineal
