Una o más bases de datos para la aplicación para muchos clientes en PHP

Estoy escribiendo una aplicación PHP en ZF. Los clientes lo usarán para vender sus productos a los clientes finales. Los clientes alojarán su aplicación en mi servidor o podrían usar la suya propia. La mayoría de ellos alojará esta aplicación en mi servidor.Una o más bases de datos para la aplicación para muchos clientes en PHP

pude diseñar una base de datos para todos los clientes a la vez, por lo que cada cliente va a utilizar la misma base de datos, sino de productos de golf, etc. serán asignados a determinado cliente. Trivial.

Podría utilizar una base de datos separada para cada cliente, por lo que la estructura de la base de datos será más simple. Probablemente usaré subdominios separados y tal vez incluso la ubicación del archivo, pero eso es solo un detalle.

¿Qué solución tendrá un mejor rendimiento y qué tan grande será la diferencia? ¿Cuál elegirías?

Fuente

2010-12-02 prostynick

No tengo una gran explicación detallada de lo que DEBERÍA hacer, pero lo que NO DEBE hacer es crear múltiples bases de datos que son esencialmente duplicados. La razón es que implementar actualizaciones/correcciones de errores se vuelve muy difícil, creando fragmentación y soporte heredado. Esto es todo gastos generales que evitarán un desarrollo eficiente en el futuro. – User123342234

@John Stuart. Pero todas son básicamente instancias únicas de la aplicación, por lo que deberían tener su propia base de datos. Si tiene 10 eshops de Magento, todos ellos tendrán su propia base de datos. ¿No los va a poner todos dentro de una base de datos? Un cliente que compromete los detalles de inicio de sesión en el servidor de base de datos y los datos de todos los clientes se verán comprometidos. –

+1 para iniciar un fuego de opiniones. :) Esta pregunta está bastante cargada. Depende de demasiadas piezas pequeñas para tener una respuesta de bala de plata. –

Utilizaría una base de datos separada para cada cliente. Hace la copia de seguridad y escalar más fácil. Si alguna vez obtiene un cliente grande que necesita algunos cambios personalizados en el esquema, puede hacerlo fácilmente.

Si un cliente necesita que restaures sus datos, con una sola base de datos es trivial. En un db compartido, mucho más difícil.

Y que si alguna vez se pone gran cliente una gran cantidad de tráfico, que fácilmente puede poner en otro servidor con cambios mínimos.

Si un sitio es comprometida, usted no tiene todos los datos teh para todos en un solo lugar, el daño está mitigado a sólo el sitio que fue hackeado.

Definitivamente recomendaría ir con 1 db por cliente si es posible.

Fuente

2010-12-02 23:14:42

¿qué harías si tienes 1000000 clientes? 1000000 bases de datos y 1000000 x N tablas.se volverá complicado e inmanejable – Ish

Cuando obtiene 1,000,000 de clientes VENDA a SAP –

@Ish Kumar: ¿En otras palabras, está sugiriendo que 1000000 eshops utilicen la misma base de datos? ¿Estas loco? –

Hasta cierto punto, esta es una cuestión de opinión personal. Hay pros y contras de ambos modelos.

En lo personal, y debido a la "Podrían utilizar su propio" comentario, me gustaría ir con una base de datos separada por cliente. Esto le da

La capacidad de mover datos de los clientes cuando sea necesario. Por ejemplo, mover un solo cliente a diferentes servidores/configuraciones dependiendo de cosas como carga.
Si algo sale mal, solo afecta a un cliente y no a todos.
Puede distribuir la carga de la base de datos entre varios servidores de bases de datos si es necesario.
Si un cliente acude a usted con un requisito específico, puede atenderlo más fácilmente sin afectar a otros clientes.

Desde el punto de vista del rendimiento, para ser honesto, no creo que haya ninguna ganancia de rendimiento real en ninguno de los modelos. Dicho esto, esto por supuesto depende de la estructura de su base de datos y del hardware en el que se ejecuta.

Fuente

2010-12-02 23:13:12 MrEyes

Al principio, iba (y aún estoy) a tener una gran base de datos. Cuando llegué con el diagrama a mi superior, lo miró y dijo: "Mmm ... pensé, vamos a tener varias bases de datos para eso". Y después de eso comencé a preguntarme cómo podría esta idea conducir a un código más claro y una mejor separación entre los clientes. Después de todo, un estúpido 'DELETE FROM' llevaría a la situación, donde solo un cliente desea matarme, no a todos ellos;) – prostynick

hay muchas maneras de protegerse de' DELETE FROM', como copias de seguridad de rutina, usando un marco robusto como cakephp, zend – Ish

-1

No elija la solución de bases de datos múltiples, si sus necesidades se pueden cumplir con una base de datos. Debido a múltiples bases de datos conducirán a gran carga en el largo plazo, y su sistema será vuelto muy complicada y difícil de manejar a medida que crece.

Usando relación apropiada se puede ir muy lejos

un modelo cliente puede tener muchos productos // ¿por múltiples bases de datos?

lata rendimiento alcanzado en cualquiera de maneras, sólo va múltiples DBS NO beneficio en esa dirección

Fuente

2010-12-02 23:14:55 Ish

Pero él está hablando de tener todos los clientes usan la misma base de datos. Imagine 1000 eshops usando la misma base de datos. Eso está mal. Cada tienda debe tener su propia base de datos. Deberían, por supuesto, tener el mismo esquema. No va a alojar 1000 blogs en una sola base de datos de WordPress tampoco. –

@Richard, el punto es que pronto se volverá inmanejable, y tener 1000 registros en la tabla de clientes y 1000 * 100 registros en la tabla de productos también está bien. Él no tiene una razón sólida para ir múltiples dbs – Ish

En cuanto al rendimiento que está básicamente comenzar con un enfoque 'sharding'. Debido a esto, la estrategia de rendimiento de sharding será pan comido.

El inconveniente es que podría argumentar que está perdiendo un poco (indefinido) de sobrecarga en la duplicación.

Una de las dificultades es que es posible que no note los problemas de rendimiento en los componentes principales tan rápido. Esto se debe a que están muy dispersos, por lo que podrían no ser visibles en su radar. La prueba de carga es la manera de adelantarse a esto.

Fuente

2010-12-02 23:16:31 Evert

definitivamente +1 para los tornillos de tuercas: ¡solo cargue la prueba y vea! – zanlok

Personalmente, me gustaría ir con múltiples bases de datos, es decir, una base de datos para cada cliente.

Según tengo entendido, todos sus clientes utilizarán solo una instancia de su aplicación para que estas instancias tengan sus propias bases de datos.

Si va con una única base de datos, está creando un gran riesgo de seguridad potencial. Un cliente que compromete los detalles de inicio de sesión en el servidor de db automáticamente comprometería los datos de todos sus clientes. También una única vulnerabilidad de seguridad (un ataque de inyección SQL) podría destruir los datos de todos los clientes (con múltiples db todavía podría tener tiempo para reparar el agujero de seguridad y liberar un parche antes de que todos los demás sitios sean atacados).

No desea tener un ejército de 1000000 clientes locos en lugar de solo 1 cliente enojado.

Múltiples bases de datos también le dan una mayor posibilidad de balanceo de carga (puede tener el dbs distribuido en más servidores).

Fuente

2010-12-03 09:23:19

+1 de acuerdo. Las implicaciones de seguridad de una sola instancia no pueden exagerarse. –

Una o más bases de datos para la aplicación para muchos clientes en PHP

Respuesta

Cuestiones relacionadas