Base de datos horizontal y vertical de base de datos

Question

Estoy trabajando en un sitio de redes sociales con un árbol familiar que es GEDCOM compatible. Tenemos que decidir si se debe utilizar una estructura de la base horizontal o vertical para los perfiles de usuario. Por lo tanto, me gustaría saber si alguien puede contestar cuándo utilizar una estructura de base de datos horizontales y cuándo usar estructura de la base vertical.

He encontrado algunas respuestas para los sitios de compras en las que no se deciden campos: una estructura de base de datos vertical debe ser utilizado. Pero estoy confundido acerca de lo que debe utilizar para un sitio árbol genealógico. ¿Debo usar vertical u horizontal?

Answer 1

Asumo que utiliza una base de datos relacional como MySQL, MS SQL, SQLite, PostgreSQL u Oracle para el almacenamiento?

Gedcom es un estándar para el intercambio de información para que sepa el número de columnas que tendrá. Tal vez la norma se amplía con nuevas propiedades en el futuro, pero probablemente no será un montón de nuevas propiedades. Se puede extender fácilmente a una mesa con algunas nuevas columnas.

Me gustaría utilizar una mesa 'horizontal' y no un-attribyte-sistema de valores entidad (tabla vertical). sistemas de mesas verticales tienden a ser lentos. No pueden ser correctamente indexada y confundir el optimizador de consultas.

Se convierte en una historia diferente cuando los usuarios pueden definir nuevas propiedades en sus perfiles como colo ojo (u) r o colo favorito (u) r sí mismos. ¿Qué tan flexible es lo que quiere que los perfiles sean?

Answer 2

bases de datos verticales son grandes para detawarehousing y leer / solamente la presentación de informes. Normalmente se vuelva a generar durante la noche. Su rendimiento de escritura es por lo general muy mala sin embargo SELECTs son 10-100 veces más rápido.

Un escenario típico para el uso de una base de datos de informes OLAP vertical es cuando se crea una instantánea (diario) de datos y luego ejecutar consultas en contra de ella. La mayor parte de los beneficios proviene de las consultas que soliciten solamente un número relativamente pequeño de campos, por ejemplo, cuando se selecciona sólo un puñado de campos de una amplia y gran mesa. Tal una consulta consulta contra millones de registros (por ejemplo, el cálculo de SUM / COUNT / AVG) tomará sólo un segundo o dos.

Su caso no parece ser un buen candidato para una base de datos vertical.

Answer 3

Estoy de acuerdo con tuinstoel, sistema de mesa / EAV vertical, no sólo es lento, pero también un tiempo muy complejo. A veces se requiere para escribir algunos de sus propios métodos de la API que se ocupan de esas tablas y los desarrolladores sólo frente a esos métodos para evitar la complejidad.

Así que si no es necesario añadir más campos y luego quedarse con mesa horizontal. Sin embargo es posible que se necesite diferente tabla si también si se va a apoyar la capacidad multilingüe. Pero te aconsejo que todavía seguir con tablas horizontales.

También estoy desarrollando un sitio que implica perfil de usuario y estoy usando tablas horizontales y si va a haber diferentes idiomas de apoyo necesarios en el futuro, entonces voy a modificar sólo para los campos donde importará idioma.