donde esta el error???

[ContraVeneno]

No me refería a eso. Lo que estas haciendo ahora:

Tener un campo tipo String donde vas agregando el ID de la matrícula, haciendo este string variable.

No me parece que sea lo correcto.

Mi sugerencia es que tengas una tabla de alumnos y matrículas como ya había explicado en este otro hilo.

Donde tendrías un Registro por cada materia cursada y no un solo campo donde cambies su valor cada ves que curse materias. Teniendo esta tabla y un registro por cada materia, no tendrías que andar inventando cosas para comparar, editar, mover o quitar materias de un campo string. Con simples instrucciones Update, Delete o Insert, puedes tener lo que necesitas sin complicartela tanto.

[UREÑA]

oye Contra no crees que voy a tener muchos registros son 37 materias por cada alumno imaginate si son 1000 alumnos??? o como vez??

[ContraVeneno]

1000 por 37 = 37,000 registros... por 10 años = 370,000 registros...

Habrá muchos de los aquí presentes que te podrían decir que 370,000 registros no son muchos.

Además, creo que vale la pena tener 370,000 registros en lugar de batallar una semana tratando de ver como hacer para quitar ciertos caracteres de una cadena.



Pero bueno, ojala y alguien tenga otra opinión sobre que es lo mejor en este caso.

Vamos, que hasta podrías consultar las reglas de normalización de bases de datos y si quieres que tu base de datos este normalizada, una de las condiciones es que los datos sean atómicos, es decir, que un valor, represente un dato.

Y si tienes un valor que representa muchos datos, pues no estarías cumpliendo con estas reglas de normalización.

[UREÑA]

pues creo que vale mas la pena perder el tiempo una semana y que las cosas queden bien echas a despues tener problemas de almacenamiento

[[Caral]]

Hola
Tablas
Alumnos, todos los alumnos.
IDAlumno, Nombre, direccion, tel, fechaentra, fechasale
Materias, todas las materias.
IDMateria, Nombre, descripcion, profesor, tipo, etc.
Cursos, todos los cursos.
IDCurso, Descripcion, profesor, Valorcurso, fechaempieza, fechatermina
AlumnoPrograma, alumnos que cursan y materias
IDAlumno, IDMateria, IDcurso, Fechaempieza, fechatermina, Notafinal
Lo que estoy es tratando de buscar una formula simple de ligar el asunto.
Que opinais.?
Saludos

[ContraVeneno]

Empezado por Caral

Hola
Tablas
Alumnos, todos los alumnos.
IDAlumno, Nombre, direccion, tel, fechaentra, fechasale
Materias, todas las materias.
IDMateria, Nombre, descripcion, profesor, tipo, etc.
Cursos, todos los cursos.
IDCurso, Descripcion, profesor, Valorcurso, fechaempieza, fechatermina
AlumnoPrograma, alumnos que cursan y materias
IDAlumno, IDMateria, IDcurso, Fechaempieza, fechatermina, Notafinal
Lo que estoy es tratando de buscar una formula simple de ligar el asunto.
Que opinais.?
Saludos

Esto es lo que me parece sería lo más correcto. Al menos es como yo lo haría. Aunque no pondría la fecha de inicio y la fecha de fin en la tabla "AlumnoPrograma" ya que estas fechas ya se encuentran en la tabla de "Cursos".

[[Caral]]

Hola
Si, El curso tiene fecha inicio y fecha final, pero el alumno terminara el curso o lo dejara a medias, es una posibilidad, otra es que el curso comience el 1 y el alumno lo comience el 3, el curso termine el 20 y el alumno no lo termine, por x razon.
Te parece logico?
Saludos

[[egostar]]

Empezado por UREÑA

pues creo que vale mas la pena perder el tiempo una semana y que las cosas queden bien echas a despues tener problemas de almacenamiento

Esto desde mi punto de vista eso que comentas sería válido con discos duros de 20 Megas, pero esos tiempos ya pasaron hace muchos años , ahora con un DD de 40 GB que creo con los mas pequeños, que problema es el almacenamiento....., no tiene nada que ver almacenamiento vs cosas bien hechas, bueno, como dije es mi humilde punto de vista.

Yo digo, vale mas invertir tiempo en crear una base de datos bien hecha (normalizada), que perder el tiempo buscando corregir inconsistencias por código.

Yo me quedo con la opinion de ContraVeneno.

Salud OS.

[[Delphius]]

Hola,
Al igual que Egostar estoy a favor de ContraVeneno.

Si tanto te preocupa el almacenamiento, podrías buscar otra alternativa de realizar dicha relación. Pero no aplicando esos artilugios que al mediano y largo plazo no sirven de nada. ¿Que harias si una materia deja de dictarse, o por el contrario, se agregan nuevas?

Si lo vemos desde el punto de vista del negocio o dominio (como prefieran llamarle) vemos que uno o más alumnos están incriptos en una o más materia. Un grupo de alumnos incriptos en una materia pueden formar una comisión.
¿Que se desprende de este texto?
Que ya sea en forma directa o indirecta existe una asociación entre los alumnos.
El análisis de dominio puede que no te haya relevado la existencia directa o explícita de relaciones. Puede que en la auditoria o análisis de campo, no se haya dicho exactamente la palabra comisión ya que según la visión del cliente o la realidad que éste tiene del negocio no le es relevante el concepto y por tanto "carece de sentido guardar algo que no le es útil"

A lo que voy es que la transformación M-M entre alumnos y estudiantes puede realizarse con otro enfoque:

Varios alumno se incriben a una comisión. Dicha comisión puede pertenecer a una o más materias. Esto puede reducir la cantidad de registros entre la antigua relación M-M ya que la asociación entre los estudiantes y las materias se ha desplazado y agrupado bajo otra tabla.

Otra cosa es si es necesario hacerle saber al usuario el concepto "comisión".

Tu verás, realizar un buen análisis del dominio o negocio puede aportarte nuevos enfoques y descubrir la manera óptima de como realizar las relaciones entre los datos.

Saludos, y que tenga exitos.