Los datos adicionales podrÃan ir en la tabla USUARIOS, pero creo que es
mejor hacer una tabla SOCIOS en la que se podrÃan poner fácilmente
validaciones de datos obligatorios; si no, estos datos serán
obligatorios para los miembros del club pero no para el resto de
usuarios, lo que no permite validar con VALIDATES_PRESENCE_OF
Si casi todos los usuarios van a ser socios, puede que estando todo en
una tabla sea más cómodo. Si no es asÃ, creo que mejor hacer las dos
tablas. Asà ocupará menos la base de datos (los usuarios no socios no
tienen los campos de socio en blanco), por lo que será más rápido, pero
sobretodo porque asà es mucho más simple y fácil de leer. Si no lo
sabes, o si puede que cambie en un futuro, haz lo segundo. Ante la duda
elige lo simple (hacer partes pequeñas y bien definidas, no todo en
uno).
Excepto que los datos como socio sean una cantidad ingente de campos, yo
creo que lo más simple es usar una única tabla y tener un campo
booleano(que
se llame socio por ejemplo) como flag, para indicar si el usuario es
socio o
no. En función de lo que valga ese campo validas unas cosas u otras.
pedir_y_validar_datos_de_club if usuario.socio
Si casi todos los usuarios van a ser socios, puede que estando todo en
una tabla sea más cómodo. Si no es asÃ, creo que mejor hacer las dos
tablas. Asà ocupará menos la base de datos (los usuarios no socios no
tienen los campos de socio en blanco), por lo que será más rápido, pero
sobretodo porque asà es mucho más simple y fácil de leer. Si no lo
sabes, o si puede que cambie en un futuro, haz lo segundo. Ante la duda
elige lo simple (hacer partes pequeñas y bien definidas, no todo en
uno).
La reflexión general es buena, y como muchos no serán socios, parece
lógico partirlo en dos.
Pero lo del Railscasts es una problemática muy diferente; allà hablan de
relación 1-n, no 1-(0,1), y resuelven el problema del alta, que en mi
caso no serÃa problema; yo el problema lo tendrÃa con el editar, que es
lo que va en una única pantalla…
Pero creo que vas por el buen camino y lo voy a hacer en dos tablas.
s2
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.