Incrustar una estructura de datos en un campo puede funcionar para casos simples, pero le impide aprovechar las bases de datos relacionales. Las bases de datos relacionales están diseñadas para buscar, actualizar, eliminar y proteger sus datos. Con un campo incrustado que contiene su propio wad-o-data (matriz, JSON, xml, etc.), termina escribiendo todo el código para hacerlo usted mismo.
Hay casos en los que el campo incrustado podría ser más adecuado, pero para esta pregunta como ejemplo, usaré un caso que destaca las ventajas de un enfoque de tabla relacionada.
Imagine un ejemplo de usuario y publicación para un blog.
Para una solución de publicación incrustada, tendría una tabla como esta (pseudocódigo; probablemente no sean ddl válidos):
create table Users {
id int auto_increment,
name varchar(200)
post text[][],
}
Con tablas relacionadas, haría algo como
create table Users {
id int auto_increment,
name varchar(200)
}
create table Posts {
id auto_increment,
user_id int,
content text
}
Herramientas de mapeo relacional de objetos (ORM) :Con la publicación incrustada, escribirá el código manualmente para agregar publicaciones a un usuario, navegar a través de publicaciones existentes, validarlas, eliminarlas, etc. Con el diseño de tabla separada, puede aprovechar ActiveRecord (o cualquier sistema relacional de objetos que desee). están usando) herramientas para esto que deberían mantener su código mucho más simple.
Flexibilidad :Imagine que desea agregar un campo de fecha a la publicación. Puede hacerlo con un campo incrustado, pero tendrá que escribir código para analizar su matriz, validar los campos, actualizar las publicaciones incrustadas existentes, etc. Con la tabla separada, esto es mucho más simple. Además, supongamos que desea agregar un editor a su sistema que apruebe todas las publicaciones. Con el ejemplo relacional esto es fácil. Como ejemplo para encontrar todas las publicaciones editadas por 'Bob' con ActiveRecord, solo necesitaría:
Editor.where(name: 'Bob').posts
Para el lado incrustado, tendría que escribir código para recorrer a cada usuario en la base de datos, analizar cada una de sus publicaciones y buscar 'Bob' en el campo del editor.
Rendimiento :Imagina que tienes 10.000 usuarios con un promedio de 100 publicaciones cada uno. Ahora desea encontrar todas las publicaciones realizadas en una fecha determinada. Con el campo incrustado, debe recorrer cada registro, analizar la matriz completa de todas las publicaciones, extraer las fechas y verificar nuevamente la que desea. Esto consumirá tanto la CPU como el disco i/0. Para la base de datos, puede indexar fácilmente el campo de fecha y extraer los registros exactos que necesita sin analizar cada publicación de cada usuario.
Estándares :El uso de una estructura de datos específica del proveedor significa que mover su aplicación a otra base de datos podría ser una molestia. Postgres parece tener un amplio conjunto de tipos de datos, pero no son lo mismo que MySQL, Oracle, SQL Server, etc. Si se apega a los tipos de datos estándar, le resultará mucho más fácil intercambiar backends.
Estos son los principales problemas que veo en la parte superior. Cometí este error y pagué el precio por ello, así que, a menos que haya una razón muy convincente para hacer lo contrario, usaría la tabla separada.
