[SOLUCIONADO] Mejor forma de estructurar la información

[rodrypaladin]

Hola chic@s. Voy a intentar realizar un script con el que el usuario podrá averiguar información sobre los tipos de extensiones de archivos.

Veamos un ejemplo:

.PDF

• Información: PDF (sigla del inglés portable document format, formato de documento portátil) es un formato de almacenamiento de documentos digitales independiente de plataformas de software o hardware
• Programas con el que poder abrir archivos .PDF: 1,2,3,4,5,6,7... con enlaces a sus páginas.
• Algo más que se me ocurra.

¿ Cual es la mejor forma de extructurar y guardar esa información ??

Una base de datos ? No tengo mucha soltura y no se me ocurre como ir creando las tablas

Unas arrays?? Sería una array multi-dimensional ?

[Erick_MD9]

Hola, yo veo 2 Opciones.

Definir completamente la informacion que mostraras de las extensiones.
1 Tabla

Tabla Extensiones
Campos:
Id
Extesion
Definicion
Uso
Historia
Enlaces
Etc
Etc

Para tener escalabilidad.
3 Tablas

Tabla Entensiones
Campos:
Id
Extension

Tabla Paricularidades
Campos:
Id
Particularidad

Tabla ExtensionParticularidad
Campos:
Id
IdExtension
IdParticularidad
Contenido

La tercera tabla une las otras 2.
Con eso es suficiente para empezar la lógica.
Espero te sirva.
Saludos

[rodrypaladin]

A poder elegir me gustaría que fuera de la siguiente forma. poniendo el mismo ejemplo:

extension .PDF:

Definición:
PDF (sigla del inglés portable document format, formato de documento portátil) es un formato de almacenamiento ..... bla bla blaaa toda la definición

Software para su lectura o manejo:

• Adobe Reader. ( con enlace )
• Adobe Acrobat Family. ( con enlace )
• bla bla bla ( con enlace )

Historia:
Los archivos PDF, junto con las aplicaciones que podían ver y crear este tipo de documentos, comenzaron a desarrollarse...bla bla bla

Características:[LIST][*]Es multiplataforma, es decir, puede ser presentado por los principales sistemas operativos (Mac, GNU/Linux, Windows o Unix), sin que se modifiquen ni el aspecto ni la estructura del documento original.[*]Puede cifrarse para proteger su contenido e incluso firmarlo digitalmente.[*]bla bla bla

¿ podría realizarlo de esta forma ?

Tabla extensiones:
id, extensión

tabla definición:
id,id_extension, definición ( cada linea una definición )

tabla software:
id,id_extensión, software ( cada linea un software con la id_extensión para indicar de que extensión lee el software )

tabla historia:
id, id_extensión, historia ( cada linea una historia )

tabla caracteristicas:
id,id_extension, características ( cada linea una caracteristica distinta y la id_extensión dice de que extensión estamos hablando )

¿ Es viable esta forma ?

[Erick_MD9]

Desde mi punto de vista, lo que planteas es lo mismo que hacerlo solo con 3 tablas.

Ejemplo
Tabla Extension
Id/Entension
1 /PDF

Tabla Particularidades
Id/Paricularidad
1 /Software para su lectura o manejo

Tabla ExtensionParticularidad
Id /IdExtension/IdParticularidad/Contenido
1 /1 / 1 /Adobe Reader. ( con enlace )
2 /1 / 1 /Adobe Acrobat Family. ( con enlace )

Saludos.

[rodrypaladin]

Veamos si lo he entendido...

Tebla extensión:
id / Extension
1 / PDF
2 / ZIP
3 / MP3

Tabla particularidades:
id / Particularidad
1 / Definición
2 / Software para su lectura o manejo
3 / Características
4 / Historia

Tabla ExtensionParticularidad
id / id_Extension / id_particularidad / contenido
1 / 1 / 1 / La definicion de PDF....
2 / 3 / 4 / La historia de la extensión MP...
3 / 2 / 2 / Caracteristicas de la extension ZIP...

Estoy en lo cierto ?

[Erick_MD9]

Sí.
Asi lo veo yo.

[rodrypaladin]

Lo probaré a ver si este método me funciona bien!!. Gracias!!

[rodrypaladin]

Ahora lo que no me queda claro es que consulta tengo que hacer por ejemplo para que me muestre todos los datos de la extensión mp3 por ejemplo...

Mostrando.. Definición..Software para su manejo y lectura...Características...Historia,

[phoneval]

Seria la mejor forma de hacerlo pero luego a la hora de leer los datos vas a tener que ejecutar 3 consultas o lo que es peor una con algún tipo de join, yo para la poca cantidad de datos que son lo metería todo en una tabla y a la hora de acceder a cada uno o a todos los que tengan una misma extensión te sobra con una consulta.
Se que esto me va a tirar al cuello a los gurus pero con tan poca cantidad de datos no creo que importe mucho engordar un poco la base de datos a cambio de menos consultas.

[rodrypaladin]

Ahora no se como realizarlo!!! Lo ideal sería que con una consulta mostrara todos los datos...

[jonni09lo]

Iniciado por phoneval

Se que esto me va a tirar al cuello a los gurus pero con tan poca cantidad de datos no creo que importe mucho engordar un poco la base de datos a cambio de menos consultas.

Pues si te van a tirar la soga al cuello porque estás recomendando malas prácticas, no importa si la base de datos es pequeña o no, es imprescindible normalizar una base de datos, por usabilidad, escabilidad y evitar la redundancia de datos. Lee esto

Iniciado por rodrypaladin

Ahora no se como realizarlo!!! Lo ideal sería que con una consulta mostrara todos los datos...

Hola @rodrypaladin, en sí ¿Qué es lo que no eres capaz de hacer? en teoría con INNER JOIN puedes traer la información de varias tablas

Saludos

[ocp001a]

Perdón por meter mi cuchara, pero cuando hablamos de tablas de una sola columna y cuyo valor no será usado en más de una tabla, me parece innecesario normalizar hasta ese nivel, ya que la ganancia de espacio de almacenamiento puede no valer la pena ante la pérdida de tiempo de proceso, al menos en mis pruebas, para una tabla de 10,000 registros con las columnas

idusuario (int), zona(varchar)
me dio los siguientes tiempos de consulta consultando 10 veces:
select * from usuarios where 1
0.0004
0.0002
0.0002
0.0002
0.0002
0.0002
0.0002
0.0003
0.0002

mientras que para dos tablas , tabla usuarios de 10,000 registros y tabla zonas de 5 registros me dio lo siguiente:
SELECT idusuario, zona FROM usuarios JOIN zonas on zonas.id=usuarios.idzona WHERE 1
0.0009
0.0003
0.0003
0.0002
0.0004
0.0003
0.0003
0.0002
0.0003

[rodrypaladin]

Ahora ya no se como estructurar la información si como tengo las tablas ahora organizadas:

Tebla extensión:
id / Extension
1 / PDF
2 / ZIP
3 / MP3

Tabla particularidades:
id / Particularidad
1 / Definición
2 / Software para su lectura o manejo
3 / Características
4 / Historia

Tabla ExtensionParticularidad
id / id_Extension / id_particularidad / contenido
1 / 1 / 1 / La definicion de PDF....
2 / 3 / 4 / La historia de la extensión MP...
3 / 2 / 2 / Caracteristicas de la extension ZIP...

O hacerlo todo en una tabla como también me están comentando.

Por otro lado @jonni09lo soy novatillo en esto y como te imaginarás no me se todas las consultas que puedo realizar, buscaré ejemplos sobre INSERT JOIN como has dicho, y si con ello consigo traer informacion de varias tablas en una sola consulta me hará mucho más fácil todo.

[jonni09lo]

Hola @rodrypaladin, con respecto a los JOIN, te recomiendo este artículo que es muy bueno ya que explica gráficamente como funcionan los distintos tipos de JOIN (algo bastante útil a la hora de tratar de entenderlos)

Con respecto al diseño de la base de datos, le decía a @ocp001a que si bien comparto la misma opinión, creo que tu base de datos podría extenderse de alguna manera, causando de que tener tres tablas no sea algo innecesario... (ese es el problema de la programación, siempre van a haber varias opciones de desarrollar un mismo problema y unas más óptimas que otras )

Saludos

[Erick_MD9]

Hola, la opción con las 3 tablas es la mejor práctica que conozco para tener mayor escalabilidad, ya que te genera una relacion muchos:muchos. La versatilidad de consultas es tan extensa que requerie tener conocimientos muy sólidos de sql.

Como comenta ocp001a, el uso de la misma depende del proyecto.

Otra forma que he usado en proyectos es una tabla DEFINICIONES.

Ejemplo aplicado al caso:

Id/TipoDefinicion/Definicion
1/Extension/PDF
2/Extension/MP3
3/Particularidad/Definición
4/Particularidad/Historia

Donde las posibilidades de TipoDefinicion deben estar preprogramadas, para el caso planteado, son solo 2; con un simple array basta.

No pierdes mucha escalabilidad y las consultas son bastante mas sencillas, requiriendo joins de solo 2 tablas, o incluso si copias los datos de tabla Definiciones en tabla de USO obtienes un resultado aceptable para datos que no requieren estricta normalización.

Saludos