Y en este otro tema q opinan?

[killerangel]

Gracias por las respuestas que me dieron en la pregunta anterior que hice.

Ahora nuevamente necesito de su ayuda:

Tengo la tabla UGEL, COLEGIO y ALUMNO. El ministerio de educacion les asigna a estas instituciones un codigo (codigo modular) de 6 digitos a cada ugel y una de 7 digitos a cada colegio, ademas los estudiantes tiene un codigo de 14 digitos dentro de la cual (a partir del 3º numero) esta el codigo de colegio (dato adicional que puede tomarse en cuenta o no) y porsupuesto un colegio pertenece a una ugel Y obviamente un alumno a un colegio.

la pregunta es: lo de los codigos es mejor trabajarlos como numeros (int? long int? 'en mysql') o mejor caracteres (char(6), char (7) y char(14) respectivamente)?

estos codigos deben conciderarse como PK de las tablas o seria mejor tener un 'id' para cada una de ellas?

y en cuanto a la herencia... sabemos que aca se tiene una relacion identificable (completa, de herencia o como desees llamarlo) de ugel, colegio y alumno respectivamente, lo que origina que cuando se haga la ficha de matricula del alumno (que tiene como 9 tablas anexas 'identificables') tiene que pasar los PK's de las tablas correspondientes a todas y c/1 de ellas... esto no le kita rendimiento (eficiencia) al server al tener que repetir esos datos en todas las tablas?
Supongamos que se le coloca como relacion no identificable (FK) igual podriamos saber a que colegio pertence un alumno y a que ugel un colegio y no tendriamos que repetir todos esos datos en tantas tablas... verdad?

que hacer?

GRACIAS DE ANTEMANO A TODOS

Cómo hacer preguntas de manera inteligente

[eduzarate]

Si vas a hacer operaciones aritmeticas con los datos usa Integer si no usa varchar yo usaria asi varchar(6) varchar(7) varchar(14). es una cuestion de espacio en byte de almacenamiento, las busquedas van a tardar lo mismo.

[seyko]

Iniciado por eduzarate

Si vas a hacer operaciones aritmeticas con los datos usa Integer si no usa varchar yo usaria asi varchar(6) varchar(7) varchar(14). es una cuestion de espacio en byte de almacenamiento, las busquedas van a tardar lo mismo.

No va a tardar lo mismo, es más rapido comparar integer que varchar.

[seyko]

killerangel, personalmente, solo pondria el codigo como varchar si necesitas que se permita tener 0s delante, del tipo "001001244", ya que si es numerico te guardaría 1001244.

Mi consejo, es que siempre que puedas la PK de las tablas sea numerica.

Un saludo

[killerangel]

Cheere!!!

Pero que hay con respecto a la segunda parte?

En la herencia ugel, colegio, alumno, es obligatorio que la pk de ugel migre a colegio a formar parte de su pk y lo mismo en alumno o puede migrar la pk de alumno pero q no sea parte de su pk sino como atributo comun?

si alumno tiene, supongamos, 20 tablas identificables, migrará a todas estas 20 tablas la pk de ugel, colegio y alumno.

si hacemos que alumno tenga solo como atributo ( no en su pk) la fk de ugel y colegio, sabremos igualmente a q clegio y ugel pertence y no habra necesidad de tener que migrar los dato de ugel y colegio a todas sus tablas lo que disminuye la eficiencia en busqueda y ocupa menos espacio...

pero....hcer eso estará bien???? esq simpre supe q en esos casos se debe colocar la ok de un padre todas que tengan herencia...

espero haberme explicado bien. gracias

[seyko]

No lo entiendo muy bien, pero de verdad vas a utilizar Herencia o lo que quieres montar es una Jerarquia??? Que tipo de Jerarquia?

Quizas estamos hablando de lo mismo, somos de países distintos, por ejemplo, no se que significa
ugel.

Por lo que entiendo, en alumno tendria una FK a colegio y donde haga falta (20 tablas) añades una FK a alumno. Si un alumno solo va a tener un registro en cada una de esas 20 tablas puedes hacer que la FK a alumno sea PK de esas 20 tablas.

No se si me explico muy bien,

A la espera

[killerangel]

pues digamos q UGEL es la institucion a la que pertenecen determinados colegios colegios, ahora veamos esto:

solo colegio y alumno...

alumno tiene una relacion identificalble con colegio, osea la pk de colegio formara parte de la pk de alumno... cierto? hasta ahi todo bien?

si alumno tiene 20 tablas que nacen de el en las 20 tablas estara la pk de alumno que sera el identificador de alumno y tambien el de colegio.

Si los datos que se colocan en las 20 tablas corresponden solo a alumnos xq deberia ir tb la pk de colegio si no interesa (para ese caso)?

ejemplo: si hay 100 colegios cada uno con 1000 alumno eso da 100000 (CIEN MIL) registros de alumnos, lo q significa q como la pk de colegio pasa a todas las 20 tablas q nacen de alumno se estara colocando 20*100000 = 2000000 (2 MILLONES!!) de veces la pk de colegio en la bd que no tendra ningun uso en particular solo la de llenar espacion innecesario. ahora piensa q pasa si migra tb la pk de ugel como parte de la pk de alumno...

Obviamente uno dice: "OYE NO TE HAGAS PROBLEMAS NO USES LA PK DE COLEGIO COMO PARTE DE LA PK DE ALUMNO Y LISTO!!!!"

pero la convencion, que yo sepa (que tengo entendido y he visto muuuuuchos ejemplos del caso alumno-colegio y similares), señala que las relaciones que son identificables.... son identificables.

ahora si espero haberme explicado, esto lo etoy haciendo xq de estas cosas me ayudo en mi tesis (TEMA Q ME COSTO BASTANTE PARA DECIDIRME) y digamos q son ciertas excepciones que pueden darse pero con debido fundamento y demostracion, mas aun si tu tema de tesis no es tan modesto jeje.

salu2

[jurena]

No soy técnico, pero te diré lo que opino.
Dices -y es cierto- que en el código del alumno ya tienes el código de colegio y de ugel, y seguramente puedes recuperar el ugel y el colegio de un alumno sin tener por qué contar con un campo FK para el colegio en la tabla de alumno y con otro FK para el ugel en la tabla de colegios, ya que podrías utilizar como FK de colegio y como FK de ugel dos substring de código alumno (imagino que es eso). Cierto que ahorras en almacenamiento, pero en cualquier caso tendrías que poner en relación ese con el código ugel y con el código colegio mediante INNER JOIN .. ON o WHERE = , para mostrar los datos concretos del colegio. Por lo demás, si lo hicieras como dices, ello te obligaría a hacer las selecciones siempre con substring y sobre un campo ordenado del que tomas una parte, en la que no sé cómo afectaría el orden (me refiero al contenido del substring en relación con el código de colegio o ugel). Y tampoco sé qué ocurriría (tiempo que tardaría en hacerlo comparado con el tiempo si usas la otra estructura) si por ejemplo tienes que sacar la media de los alumnos por colegios si tienes que agrupar por substring().
Por otra parte, no sé por qué tienes que almacenar en las 20 tablas de los alumnos el código del colegio y el ugel. Te bastará tener almacenado el código del colegio en una tabla, la tabla donde aparecen los datos más significativos del alumno, pues por él podrás llegar al colegio y por el colegio sacarás el ugel (en la tabla colegio tendrás el ugel correspondiente como FK) de cada alumno. Si tienes otras 19 tablas referidas al alumno, tendrás un campo en el que incluirás el código del alumno, porque, si no, no podrás establecer la relación, y con él también podrás llegar siempre al colegio a través de la tabla donde tienes los datos significativos del alumno, y por el colegio al ugel.
La pregunta la deberán responder los técnicos, pero cuando tengas muchos datos, creo que te irá mejor una relación bien establecida con índices adecuados que te ayude a recuperar los datos que hacerlo trayéndote ugel y colegio desde el código de alumno. Imagina una consulta más o menos simple sobre diferencia de las calificaciones de los alumnos varones de un grupo sobre la media del colegio, y todo eso teniendo que usar un where substring(alumno.codigo,-9,6) = ugel.códigocolegio, o un group by substring(alumno.codigo,-9,6) sin poder, según creo, aprovechar el uso de los índices adecuadamente (tendrías que hacer dos índices y sobre una parte distinta de la cadena del código del alumno, y además de derecha a izquierda y no de principio a parte), en lugar de recurrir a un INNER JOIN que se aproveche bien de los índices y te deje más claro el código por lo que a la consulta se refiere.
Y si trataras el nombre del colegio y de ugel como meras etiquetas, no habría tanto problema e incluso yo pensaría en que es mejor sacar todo desde el código del alumno, pero agrupaciones para extraer datos estadísticos sobre grupos (ugel y colegio) quizás te hagan repensar tu primera idea.

Como ves, no tengo muchas respuestas concretas, sino preguntas que me hago a mí mismo para las que yo no tengo respuesta técnica.
Saludos.

[seyko]

Iniciado por killerangel

Obviamente uno dice: "OYE NO TE HAGAS PROBLEMAS NO USES LA PK DE COLEGIO COMO PARTE DE LA PK DE ALUMNO Y LISTO!!!!"

pero la convencion, que yo sepa (que tengo entendido y he visto muuuuuchos ejemplos del caso alumno-colegio y similares), señala que las relaciones que son identificables.... son identificables.

Para mi colegio seria FK de alumno, núnca formaria parte de su PK.

No se a que te refieres, exactamente, con identificable, pero colegio no es dependiente de alumno, por tanto la PK de colegio no tiene que estar en la PK de alumno. Un colegio solo existe si tiene un alumno??? Segun mi punto de vista, no.

Por tanto, para mi es simple, PK de alumno, por ejemplo ID_ALUMNO, con una FK de colegio, y para el resto de tabla FK ID_ALUMNO.

Espero haberme hecho entender.

Un saludo

[killerangel]

Bien!!

Entiendo ahora mejor, de hecho estube tambien analizandolo con las profundidad y de esa manera evito mucha redundancia y a la vez se da mayor eficiencia a las busquedas y consultas.

Gracias a toos...

[ani_bsb]

me puedes ayudar en saber como obtengo el codigo modular de mi hija o si lo tiene sin tener que recurrir al colegio dond estuvo estudiando por favor la infomacion que me puedas dar te la agradecere un monton y lo mas pronto posible gracias

[gnzsoloyo]

Me parece que estás un poco extraviado: Este foro es para desarrollo de bases de datos y SQL, no para dar asistencia a gestiones personales con trámites burocráticos.
No te enojes, pero creo que te has confundido de foro, o incluso de sitio web.