Hola

Tengo unas dudas existenciales. Cero que son dudas de concepto y me gustaria que me contestara gente con esperiencia en BD como vosotros.

Estoy haciendo un programa en c# que ataca a una BD MySQL. La intencion es que si el cliente lo exije la base de datos se pueda migrarla a otras BD's, sean Oracle o MSSQL Server. Pero la opción inicial es MySQL.de momento 4.1

Resulta que tengo que introducir espedienes en una tabla. Los espedientes han de ser unicos en la tabla y el numero de expediente es una cadena de unos 10 digitos (año/NoExpediente) Ej: 05/0000015 Los numeros de expedientes siempre han de tener numeros correlativos y cuando se inicie un nuevo año se ha de reinicializar. Es decir 05/0929209 05/0929210 06/0000001 06/0000002 No se eliminaran expedientes pero muy ocasionalmente puede suceder la eliminacion de uno. (3 o 4 al año). O eliminar expedientes creados por error. Es decir. se crean y se eliminan inmediatamente. Los numeros de expediente los ha de generar el programa/bd pero ocasionalmente el usuario puede introducir el numero de expediente para cubrir los huecos generados por las eliminaciones si lo cree necesario. Esta tabla está relacionada con muchas tablas.

Inicialmente creé la tabla com la clave primaria, el numero de expediente. Esto me iva bien porque al ser la clave primaria unica, al ser un programa multi usuario,y si se genera el numero de expediente no correcto, al realizar la inserción se generava un error(por duplicado) y lo solucionava a posteriori.

Voy a un curso de programacion en php Y hemos hecho unos ejemplos que atacan a MySQL y parece ser que a mi profa le gustan mucho los pk autonumericos. Le he comentado el ejemplo y efectivamente ella pondria com PK un int autonumerico y el numero de expediente como atributo. Ella me comenta al estar relacionada la tabla con otras y al existir muchos registros, la clave primaria de esta tabla ha de estar en las otras tablas como clave foraneas. Problema:Las selecs seran más lentas con strins que con integers i la BD ocupará más espacio. (cierto, pero es tan critico el espacio que gasto entre una llave string i un int auto numerico' en muchas tablas maximo 10-15 tablas.) Importa el tipo en las llaves primarias en las selecs i selecs anidadas? ¿? Yo creo que seria más complicado controlar los duplicados en los numeros de expedientes.

En este caso no mo dificaria mi diseño. Que pensais?

Otro tema pero relacionado.

Yo no he utilizado en ninguna tabla autonumericos para las claves primarias i puede que en este caso si que me he equibocado. Por ejemplo tengo una taba clientes. En esta tabla se introducen los datos de los clientes realcionados con los expedientes.Existirán relativamente muy muy pocos clientes que intervengan en varios expedientes.Pero los datos de los clientes en estos casos suelen ser diferentes (cambio de domicilio,.otros datos...)Por eso he decidido introducir los datos de los clientes tantas veces como espedientes intervenga. Inicialmente la clave primaria de esta tabla era una clave compuesta (nexpediente, n de cliente dentro de expediente) En principio no tenia problemas, pero al relacionar esta tabla con otras (relacion 1-n) la llave primaria (compuesta) ha de estar como llave forania en la otra tabla. y esto se complica si esta se relaciona con otra.

Con esto tengo muchos problemas,me estoy pensando en crear una llave primaria independiente y las llaves foraneas no formen parte de la clave primaria de la tabla. Voy bien? Esta clave primaria la hago que sea int unsigned, auto incremental??.

En esta BD querré hacer backups y no quiero preocuparme de los numeros de los auto incrementales. Esque los backups i la restauración de estos lo quiero hacer dede el mismo programa que realizo. Mi pregunta es si tendré problemas en la restauracion de estos backups. Esque tengo malas esperiencias en los auto incrementales cuando utilicé Access en una aplicación.

Tendré problemas si alguna vez me piden migrar la bd a otra BD sea Oracle o MSSQL Server con los auto incrementales?

Que herramienta para modelar la BD me recomendais si el modelo no quiero que esté ligado a un modelo Fisico. Es decir diseñar el modelo logico i decidir depues si quiero en modelo fisico en MySql, Oracle, MSSql Server... Y lo mas importante... Bueno, bonito y barato.

Muchas gracias a todos vosotros que habes leido todo el mensage. Creo que me he pasado un poco escribiendo. ;)

Saludos

Ramon