Lo que dice Vice es cierto... hay que tratar de abstraer lo más posible...
En bases de datos existe un tema llamado "especialización-generalización" que es análogo a la herencia entre clases (en orientación a objetos).
En este caso, las tres tablas sí pueden tener una relación (indirecta) a través de un padre común.
Un tabla "Inmueble" que tiene todos los campos comunes de todos los inmuebles:
*******************************
+ INMUEBLE:
----------
- id_inmueble (PK) (FK)
- tipo_inmueble (PK)
- provincia (campo común a todos)
- precio (campo común)
- más campos comunes.
*****************************
el id_imueble es una clave foránea (FK) que es primaria en la tabla específica ( id_piso, id_atico, etc).
el tipo_inmueble es un indicador del tipo de inmueble y sirve para discriminar registros. (también para acelerar las búsquedas) (¿piso?, ¿atico?, etc).
Ambos campos componen la clave primaria.
Luego, ya haces las otras tablas específicas, que serán hijas de INMUEBLE:
*****************************
+ PISO:
-----
- id_piso (PK)
- campo propio 1
- Más campos propios
************************
+ ATICO:
-----
- id_atico (PK)
- campo propio 1
- Más campos propios
*****************
Ahora ya tienes las tablas relacionadas. Las lecturas son más fáciles y rápidas, pero las escrituras son un poco más lentas. ¿Por qué?
- Antes tenías que hacer tres consultas a tres tablas para poder resolver tu problema.
Ahora sólo harás una consulta a una tabla. Ganas muchísimo al leer!
- Antes para registrar un nuevo inmueble simplemente lo agregabas a una tabla. Ahora vasa a tener que escribir en dos tablas, en una, registras el inmueble específico y en otra los campos comunes. Pierdes un poco.
Esto SIEMPRE va a pasar, si quieres ganar velocidad de lectura, perderás de escritura y viceversa).
******************************
Y ahora puedes tener la información común en una solo resultset, con lo que podrás utilizar cualquier script de paginación.
saludos