Datos de registro ¿en una tabla o en dos?

Un usuario se registra y se guardan sus datos en la tabla USUARIOS.

Después puede, si quiere, hacerse miembro del Club, en cuyo caso se le
piden datos adicionales.

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

Pero después hay otra página, la ficha del usuario, en la que se tienen
que poder editar tanto los datos de usuario como los del club (¿tabla
SOCIOS?), y no sé si va a ser un problema que estén en tablas distintas.

¿crees que es mejor poner los datos de usuarios y socios en tablas
diferentes, o en una tabla única? ¿por qué?

Fernando C. wrote:

Pero después hay otra página, la ficha del usuario, en la que se tienen
que poder editar tanto los datos de usuario como los del club (¿tabla
SOCIOS?), y no sé si va a ser un problema que estén en tablas distintas.

No debería ser un problema [1]

¿crees que es mejor poner los datos de usuarios y socios en tablas
diferentes, o en una tabla única? ¿por qué?

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).

Saludos,

Héctor.

[1] http://railscasts.com/episodes/73

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

On Nov 12, 2007 6:02 PM, Fernando C. <

Héctor Pérez Arenas wrote:

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).

Saludos,

Héctor.

[1] http://railscasts.com/episodes/73

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