Jose Juan

http://jose-juan.computer-mind.com

Karma: 66 puntos de 100

Miembro de Genbetadev desde

Experto para 7 usuarios

Sin actividad desde hace un mes

A veces resulto ser un pesado... perdón.Sí, soy un ignorante de la fotografía... perdón también (como cuando no sabía que hacía un tío en moto con un acordeón haciendo fotos).

Expertos de en Genbetadev

no ha añadido ningún experto todavía

Jose Juan ha hecho 549 comentarios en Genbetadev:

  • 4 brillantes
  • 53 interesantes
  • 476 normales
  • 16 flojos
  • 0 irrelevantes
3

En Migración de costes (o el castigo de Sísifo)

  • karma: 20 | normal
  • 25 de junio de 2014 a las 00:00
23

En Bases de Datos y relaciones ternarias

@lalilolala, la entidad IMPARTICIÓN define una clase impartida por un profesor en un momento dado y al que han asistido determinados alumnos, por tanto, la tabla IMPARTICIÓN tiene sus propios datos (fechora de inicio, fechora de término, título con que se publicó en el panel, etc...) así, tiene su propia clave ImparticiónPk que identifica unívocamente cada impartición de las demás. Dicha clave, NO depende de ninguna otra (un profesor puede impartir muchas veces, un alumno asistir muchas veces, etc...).Como *DATOS* (además de los mencionados antes), la tabla IMPARTICIÓN tendrá algunas claves foráneas, como el aula física en la que se impartió, por ejemplo AulaFk, pero dichas claves foráneas *NO IDENTIFICAN* la impartición, porque perfectamente puede ser que haya varias imparticiones en el mismo aula y para el mismo curso (incluso mismo profesor, mismo título, etc...)."Este es un tema que nunca sé como encarar y acabo siempre utilizando claves compuestas enormes"En general, *TODAS* las entidades deben tener su propia clave primaria *INDEPENDIENTE* de cualquier otra.Por ejemplo, *EN PRINCIPIO* la tabla IMPARTICION_ALUMNO podría definirse con la clave primaria { *ImparticiónPk, *AlumnoPk }Pero *EN GENERAL* siempre es preferible hacer lo siguiente: { *Id, +ImparticiónFk, +AlumnoFk }donde { +ImparticiónFk, +AlumnoFk } definen (conjuntamente) una restricción UNIQUE.¡Pero! aunque en general debiera hacerse así (y perfectamente puedes usarlo como regla general a seguir) hay situaciones en las que, en la práctica, no se hace.Por ejemplo, un refinamiento de la regla general anterior, podría ser la siguiente: "siempre que otras tablas dependan de ella, crearemos una clave primaria explícita, en otro caso, podemos usar claves ajenas".Así, si prevemos que la tabla IMPARTICIÓN_ALUMNO *NO* va a ser referenciada por otras (ej. IMPARTICIÓN_ALUMNO_PREGUNTA_AL_PROFESOR) entonces podemos dejarla como: { *ImparticiónPk, *AlumnoPk }en otro caso, haríamos { *Id, +ImparticiónFk, +AlumnoFk }y por ejemplo, la tabla IMPARTICIÓN_ALUMNO_PREGUNTA_AL_PROFESOR se definiría como { *Id IDENTITY(1,1) , +AsistenciaFk (IMPARTICIÓN_ALUMNO.Id) , Pregunta STRING }El modelo será coherente y libre de ambigüedades, pero el coste es que en las consultas habrá más productos cartesianos (y por tanto se penaliza el rendimiento), lo cual se solventa fácilmente creando vistas indizadas, por ejemplo de SELECT a.AlumnoPk, b.Id as PreguntaPk FROM IMPARTICIÓN_ALUMNO a JOIN IMPARTICIÓN_ALUMNO_PREGUNTA_AL_PROFESOR b ON a.Id = b.AsistenciaFkque nos evitará tener que hacer un CROSS frecuente contra la tabla IMPARTICIÓN_ALUMNO (ej. si es frecuente hacer consultas sobre TODAS las preguntas que ha hecho un alumno con independencia de las imparticiones en que ocurren).;)
  • karma: 10 | normal
  • 08 de julio de 2014 a las 00:00
19

En Métodos Singleton

Relativo a los comentarios sobre las instancias singleton, tener en cuenta que puede haber múltiples instancias de dicha clase (no sólo una aunque se llame "singleton"). La "instancia única" es relativa al contexto en el que se comparte dicha instancia.El contexto "canónico", vendría a ser el proceso (que no thread) que ejecuta el programa, pero yo recomendaría pensar siempre y de forma explícita en el *CONTEXTO* de instancia del singleton.Por poner otros ejemplos, podríamos tener una clase singleton a nivel distribuido, en el que múltiples nodos comparten la misma instancia (obviamente habrá instancias en cada nodo, pero todas ellas están sincronizadas como una sola), el singleton abstrae toda la sincronía entre todos los nodos, de hecho, los invocantes no tienen porqué saber si es o no distribuida.Un singleton muy útil (para mi) es a nivel de solicitud en un servidor, en el que el contexto de la instancia queda determinado por el procesamiento request/response; el singleton, abstrae su comportamiento dentro de toda la petición.Un singleton menos común relacionado pero diferente al anterior, podría ser aquel que obtiene las cadenas internacionalizadas (traducidas a cierto idioma) en ciertas peticiones en el servidor. En este caso, el contexto podría ser el idioma preferido indicado en el useragent; el singleton, abstrae su comportamiento desde que arranca el servidor hasta que se detiene (ej. un request/response puede usarlo haciendo "SingletonTraslations.Translate(text)" ignorando el contexto concreto).Por poner un ejemplo de un singleton ridículo y absurdo pero que expresa la idea de "contexto", podría ser aquel que lanza un dado y devuelve la instancia n-ésima del valor obtenido. El "contexto", sería la "suerte" que tiene el que invoca (ej. "SingletonAbsurdo.Current").Así, el singleton permite mantener un estado bajo un contexto que el invocante no tiene ni porqué conocer, lo cual, es bueno, si el invocante no necesita controlar dicho contexto.Tan malo es ir arrastrando dependencias cuando no es necesario (en cuyo caso mejor usar singleton), como no arrastraslas y luego querer controlar el contexto (en cuyo caso, mejor inyectar). Todo depende :)
  • karma: 10 | normal
  • 22 de mayo de 2014 a las 00:00
12

En Atom, el editor de código de GitHub, ya es software libre

  • karma: 10 | normal
  • 07 de mayo de 2014 a las 00:00
31

En ¿Qué pasa con JavaScript?

  • karma: 55 | interesante
  • 08 de abril de 2014 a las 00:00
2

En Programación declarativa: el superbuscador (IV)

  • karma: 13 | normal
  • 26 de marzo de 2014 a las 00:00
Página 1 de 25 páginas

Volver al perfil de Jose Juan »