Debo registrar unas solicitudes, el problema radica en que las solicitudes las puede hacer una comunidad o una institución pero los campos son los mismos, tengo una tabla para comunidades y una para instituciones, que me recomiendan, creo 2 tablas, una para solicitudes por comunidades y una para solicitudes por instituciones? o creo una sola tabla con id de solicitantes y el id de comunidades y que quede en nulo 1 cuando haga un registro?
Yo te recomiendo usar una sola tabla, porque dices que tienes los mismos campos en ambos;
Ahora, para distinguir si es Institución o Comunidad puedes agregar un campo que diga que tipo está realizando
la solicitud.
Así te ahorras crear otra tabla, y optimizar código también.
ok, entonces creo 1 sola tabla y agrego el id de institucion y el id de comunidad y que cuando sea de un tipo el otro quede null?
No brother, crea una tabla y agregas un campo que identifique que tipo es si es comunidad o institución; por ejemplo:
Tabla A
Nombre (Nombre de la institución o comunidad)
Tipo (comunidad o institución)
Campo3
Campo4
Ya cuando tengas que elegir en la interfaz de tu sistema ya que te muestre en un combobox para seleccionar
que tipo es: institución o comunidad y guardas ese dato en el campo que dice Tipo de la tabla A.
Espero que me entiendas.
no pero la comunidad y la institución son 2 tablas diferentes a parte de la tabla de solicitudes que quiero crear
Si tanto la tabla de comunidad como la de institución tienen las mismos campos, no veo porque lo divides. Podrías
unirlo y ya identificar con otro campo el tipo, pero si ya es obligatorio como lo tienes seguiré pensando en alguna forma para desarrollarlo como tu deseas.
No tienen los mismos campos por eso es el problema, dije que tendrían los mismos campos pero la de solicitudes si hacia 2 tablas.
Es sabio siempre tener en mente las reglas de normalización de BBDD; evitan muchos problemas posteriores. Por ejemplo se me ocurre que con 2 tablas puedes tener duplicidad de las llaves foráneas de la solicitud que apuntan al solicitante; ¿a qué tabla pertenece?
Considera usar una tabla maestra que contenga un campo de tipo y todos los campos necesarios de ambos tipos de solicitantes, y cuyo modelo es una superclase. Entonces puedes utilizar el patrón de diseño Factory para instanciar modelos separados para comunidades e instituciones (subclases) donde solo acceden a sus respectivos campos además de los que tengan en común. Los que no les pertenecen son "invisibles" ni tampoco ocupan espacio en la tabla. Y las llaves foráneas de la solicitud son inequívocas pues solo apuntan a una tabla.
¿Que es un patrón de diseño Factory? y disculpa nunca lo he utilizado.
Miguel:
No voy a entrar en una explicación técnica ni complicada ya que puedes buscarlo en Google. Para los efectos de tu aplicación el modelo de la tabla maestra que contiene todos los campos para ambos solicitantes es la fábrica ("factory"). Esta es la superclase de donde se derivan ("fabrican") dos subclases: un modelo para las instituciones y otro modelo para las comunidades. Además de definir sus propios atributos, ambos modelos pueden tener en común cero o más propiedades/atributos/campos de la tabla maestra.
modelo Solicitante.php:
class Solicitante extends CActiverecord
{
public function tableName()
{
return 'Solicitante';
}
// definición de los atributos en común
...
}
modelo Institucion.php
class Institucion extends Solicitante
{
// definición de los atributos específicos de la institucion - los comunes ya están disponibles
}
...
modelo Comunidad.php
class Comunidad extends Solicitante
{
// definición de los atributos específicos de la comunidad - los comunes ya están disponibles
...
}
En la solicitud y dependiendo del tipo de solicitante escoges el modelo y defines los campos específicos a poblar. En ambos casos trabajas con una sola tabla así que evitas los problemas antes mencionados.
Espero haber explicado satisfactoriamente; de lo contrario me avisas.
entendí mas o menos no soy muy conocedor de MVC pero lo intentare gracias 