Foros del Web » Programando para Internet » PHP »

Esta inquietud me vuelve loco, y debe ser re facil resolverla

Estas en el tema de Esta inquietud me vuelve loco, y debe ser re facil resolverla en el foro de PHP en Foros del Web. A ver si me pueden sacar esta duda: Necesito sabes cual es la forma correcta de implementar una tabla en la BD para setear la ...
  #1 (permalink)  
Antiguo 16/07/2003, 02:05
 
Fecha de Ingreso: junio-2002
Ubicación: Buenos Aires, Argentina
Mensajes: 876
Antigüedad: 15 años, 6 meses
Puntos: 0
Esta inquietud me vuelve loco, y debe ser re facil resolverla

A ver si me pueden sacar esta duda:

Necesito sabes cual es la forma correcta de implementar una tabla en la BD para setear la congifuracion general de un sitio, por ejemplo si esta en mantenimiento, etc.

Yo habia pensado en una tabla de un solo registro y con tantos campos como cosas para configurar. De esta forma con un simple SELECT y sin un a condicion WHILE extraeria todos los valores. Luego de un mysql_fetch_array accederia a los valores directamente con un $campo['nombre_de_campo'].

Pero he visto una aplicacion prefabricada que lo hace diferente. Usa una tabla de solo dos campos "variable" y "value" y usa tantos registros como cosas a configurar. Luego de hacer la consulta, para acceder a todos los valores se maneja con un while:

while ($row = mysql_fetch_array($request))
$settings[$row['variable']] = $row['value'];

Y yo me pregunto: que ventaja trae este metodo? O sea, con el mio me ahorraba el while ya que era un solo registro. Es cierto, eran seguramente muchisimos campos para la tabla, pero esto importa?


Y la misma duda me surje si quiesiera implementar una tabla para organizar los diferentes skins del sitio (color, nombre del skin a mostrar al usuario, medidas de tabla, etc).
En este caso se me ocurre implementar la solucion que yo habia pensado para el caso anterior, y esta vez coincide con la forma de trabajar de otro script prefabricado que encontre.
O sea, usa una tabla de una cantidad de campos igual a las cosas a setear en el skin, por ejemplo: nombre, color1, color2, etc. Y usa tantos registros como skins. Asi, como dije antes, luego del select todos los valores del skin estan a mano sin necesidad de hacer un while, ya que se trata de un solo registro.


Bueno, despues de pensar estas dos cosas y viendo las diferentes implementaciones que se les da en diferentes scripts prefabricados, ahora estoy confundido acerca de como hacerlo en mi sitio.
Talvez este confundido y las dos cosas que quiero hacer se hacen de diferentes formas, tal como comente que lo hacian esos scripts. O tal vez la forma de hacer esto sea la misma para el caso de la configuracion general y el caso de los skins, y por lo tanto uno de los dos scripts prefabricados que mire no lo hace de la mejor forma.

Por favor, saquenme de esta duda, aconsejenme que les parece que deberia hacer en cada caso.
  #2 (permalink)  
Antiguo 16/07/2003, 04:45
Ex Colaborador
 
Fecha de Ingreso: junio-2002
Mensajes: 9.091
Antigüedad: 15 años, 5 meses
Puntos: 16
Hola,

Todo depende. La solucion de un registro por opcion es valida y recomendable (en mi opinion) si tienes un numero indefinido o grande de opciones que se pueden almacenar en un un solo tipo de campo. La solucion de un registro con un campo para cada opcion es valida y recomendable (en mi opinion) si tienes un numero fijo de opciones que son de distintos tipos de dato.

La opcion de una opcion por registro es buena para ampliar el numero de opciones sin modificar la estructura de la tabla. Simplemente añades un registro mas. Tambien facilita la cosa si no es obligatorio que todas las opciones tengan valor. Solo creas el registro para las opciones que tienen valor.

En cuestion de rendimiento, no se que es peor, si leer 1 solo registro con 50 campos o leer 50 registros de 2 campos. En este caso tampoco creo que importe. Es mas, podrias (deberias) "ocultar" todo el trabajo con las opciones con funciones (o mejor una clase) y probar las dos implementaciones. Incluso podrias usar una implementacion en fase de desarrollo y otra en produccion.

Luego esta lo mas importante: tus gustos. Si estas mas comodo (y eres mas productivo) con un sistema que con el otro, usalo.

Saludos.

PD: Es mi opinion. No es la verdad absoluta. Prueba y decide por ti mismo.
__________________
Josemi

Aprendiz de mucho, maestro de poco.
  #3 (permalink)  
Antiguo 16/07/2003, 12:37
 
Fecha de Ingreso: junio-2002
Ubicación: Buenos Aires, Argentina
Mensajes: 876
Antigüedad: 15 años, 6 meses
Puntos: 0
Gracias por responder...
Por ahora, el numero de opciones a setear seria fijo, no tengo intencion de ir agregando nada con el tiempo.
En el caso de la configuracion del sitio serian unas 30 opciones fijas, y en el caso de los skins, no estoy seguro, pero supongamos unas 20.

Yo voy a hacer pruebas, claro, pero me gustaria saber nuevamente tu opinion, y la del que quiera hacerme cualquier comentario.

Gracias.
  #4 (permalink)  
Antiguo 16/07/2003, 14:22
Ex Colaborador
 
Fecha de Ingreso: junio-2002
Mensajes: 9.091
Antigüedad: 15 años, 5 meses
Puntos: 16
Bueno, ya te digo que las dos soluciones son buenas.

Pensando he encontrado otra opcion: un registro con un campo. El campo seria TEXT (el mas grande). Funcionaria partiendo de la idea de que todas las opciones las vas a menjar en PHP como un array. Es decir, tendras un array con los distintos valores de las opciones y sera ese array lo que leas y modifiques. La idea seria serialazar ese array y guardarlo en base64 para que no haya problemas con caracteres raros. Por ejemplo;
Código PHP:
<?php
$opciones
['Idioma']='Castellano';
$opciones['Fecha']=array('Formato'=>'%d-%m-%Y','GMT'=>1);
$opciones['Colores']=array('Color1'=>'0xff00ff','Color2'=>'0x0000ff','Color3'=>'0xf0f0ff');
$opciones['Numero']=1024;

//lo serializas (pasas a string)
$opciones_serializado=serialize($opciones);
//se codifica en base64
$opciones_base64=base64_encode($opciones_serializado);
// guardamos en la base de datos el valor
$sql="update opciones set opciones='$opciones_base64' where id=1';  // por ejemplo
?>
.
.
.
<?php
// si queremos recuperar el array de opciones
// supongo que en $row['opciones'] esta el campo
$opciones=unserialize(base64_decode($row['opciones']));
// ahora tienes en $opciones todas las opciones como en el array original
print_r($opciones);
?>
Este metodo es ideal de la muerte si quieres tener las opciones en un array con una estructura algo complicada (pesada de reconstruir campo a campo). Un inconveniente es que de esta forma estas obligado a leer y escribir todas las opciones juntas, es decir, si solo quieres usar un par de opciones, primero debes leer de BD todas las opciones y luego acceder al array. Y otro inconveniente es que de esta forma ocupa mas espacio. Al serializar el array se añade informacion de la estructura del array (haz un echo $opciones_serializado;) y despues con base64 se aumenta mas el tamaño.

Como todo en esto de la programacion, tienes multiples soluciones que funcionan, cada una con sus pros y sus contras. Debes analizar tu situacion y aplicar la que mas conveniente te parezca.

Saludos.

PD: Quien dice un array dice un objeto.
__________________
Josemi

Aprendiz de mucho, maestro de poco.
  #5 (permalink)  
Antiguo 16/07/2003, 21:51
 
Fecha de Ingreso: junio-2002
Ubicación: Buenos Aires, Argentina
Mensajes: 876
Antigüedad: 15 años, 6 meses
Puntos: 0
Gracias nuevamente.
No voy a dejar opcion sin probar antes de elegir la que mas me guste
Atención: Estás leyendo un tema que no tiene actividad desde hace más de 6 MESES, te recomendamos abrir un Nuevo tema en lugar de responder al actual.
Respuesta




La zona horaria es GMT -6. Ahora son las 15:06.