En un sitio con una cantidad razonable de tráfico, ¿importaría si la aplicación/lógica comercial se escribe como procedimientos almacenados, activadores y vistas, en lugar de dentro del código PHP?¿Lógica empresarial en PHP o MySQL?
¿Cuál sería la mejor manera de seguir teniendo en cuenta la escalabilidad?
No puedo proporcionarle estadísticas, pero a menos que planee cambiar PHP para otro idioma en el futuro, puedo decir que mantener la lógica de negocios en PHP es más "escalable".
Siempre es más fácil y más barato resolver los problemas de carga del servidor web que tenerlos en la base de datos. Su base de datos siempre tendrá que iluminarse rápidamente y simplemente arrojar espejos no resolverá el problema. Cuantos más esclavos de bases de datos tenga, más escrituras tendrá que hacer.
+1 .. Sí, eso es exactamente lo que estaba pensando ... puedo cargar el equilibrio de PHP, pero cómo equilibrar la carga de MySQL. –
Una aplicación PHP bien hecha debería ser suficiente, pero tenga en cuenta que también requiere que haga menos llamadas a la base de datos que pueda. Almacene los valores que necesitará más adelante en PHP, acorte las consultas, caché, etc.
La optimización de MySQL siempre es imprescindible, ya que también reducirá la cantidad de llamadas a databse por PHP, y así obtendrá un mejor rendimiento. Por lo tanto, no hay manera de que no pueda pensar en procedimientos almacenados, etc., si su objetivo es aumentar el rendimiento. Pero MySQL por sí solo no sería suficiente si tu código PHP no está bien hecho (muchas llamadas innecesarias a la base de datos), es por eso que creo que PHP debe estar bien codificado, teniendo en cuenta el proceso del agujero mientras lo desarrollas, de modo que cosas innecesarias no se interpone en el camino La memoria caché, por ejemplo, en "dúo" con MySQL adecuado, es un gran impulso en el rendimiento.
¿Puede respaldarlo con algo de experiencia personal y/o datos estadísticos que respondan específicamente a la cuestión de la escalabilidad? –
En mi experiencia, debe poner lógica de negocio en código PHP en lugar de moverlo a la base de datos. Asumiendo que su base de datos está en un servidor independiente, que no quiere que su base de datos para el cálculo de fórmulas estar ocupado cuando las solicitudes entran en juego.
mantener su base de datos de un rayo rápido para manejar selecciona, inserciones y actualizaciones.
Creo que tendrá una mayor escalabilidad al mantener el código de la base de datos en la base de datos donde se puede ajustar el rendimiento a medida que aumenta el número de registros. También tendrá una mejor integridad de datos, que es fundamental para los datos, incluso siendo útil. No se ve una gran cantidad de db relacionales de tamaño terrabyte con todo su código en la aplicación.
Lea algunos libros sobre la optimización del rendimiento de la base de datos y luego decida si quiere arriesgar los datos de su empresa en el código de la aplicación.
Después de tantos años de poner todo en el PHP, he comenzado a sentir que tener la lógica en el DB hace que muchas cosas sean más fáciles, más centrales y más transparentes. Sin embargo, cuando pienso en la escalabilidad, de alguna manera parece que el equilibrio de carga de PHP es más fácil y más barato, y no creo que pueda decir lo mismo de MySQL. ¿Puede arrojar algo de luz sobre eso, por favor? –
Hay varias cosas que se deben tener en cuenta al intentar decidir si ubicar la lógica de negocios en la base de datos o en el código de la aplicación.
se tendrá acceso a la misma base de datos desde diferentes sitios web/web aplicaciones? ¿Las aplicaciones de sitios/ se escribirán en el mismo idioma o en otro idioma?
Si la base de datos se utilizará a partir de un solo sitio, y el sitio está escrito en un lenguaje único, entonces esto se convierte en un no-tema. De lo contrario, tendrá que considerar la complejidad adicional de los procedimientos almacenados, desencadenantes, etc. frente a tratar de mantener la lógica de acceso a la base de datos, etc. en múltiples bases de código.
¿Cuáles son las bases de datos relacionales en bien general para MySQL y lo que es bueno para específicamente? ¿Qué es PHP mejor?
Esta consideración es bastante directa. Las bases de datos relacionales en general y específicamente en cualquier variante de SQL van a hacer un gran trabajo en la inserción, actualización y eliminación de datos. En general, también manejan bien las transacciones ATOMIC. Sin embargo, la mayoría de las variantes de SQL (incluido MySQL) no son buenas en cálculos complejos, manejo de fechas sobre la marcha, acceso al sistema de archivos, etc.
PHP por otro lado es muy rápido en el manejo de cálculos, fechas, sistema de archivos accesos. Si se toma un poco de tiempo, incluso puede diseñar su código PHP para que funcione de tal manera que los registros solo se recuperan una vez y luego se almacenan cuando es necesario.
¿Qué estás más familiarizado/ cómodo con el uso?
Obviamente, tiende a tener más sentido utilizar la herramienta con la que está más familiarizado.
Como último punto, considere que el hecho de que un taladro pueda usarse para cortar chapa o porque un martillo puede usarse para mover un tornillo no significa que deba usarse para estas cosas. A veces pienso que los programadores hacen más daño potencial al tratar de hacer herramientas más poderosas que hacen todo en lugar de hacer herramientas más simples que hacen una cosa realmente bien.
Todos los puntos válidos. Pero la parte que realmente tengo que entender es si tener la facilidad para aplicar la lógica de biz en el nivel de DB era una mala idea, ¿por qué veríamos tantos DBA tan bien pagados y tan buscados en el mundo? –
MySQL apesta al usar técnicas avanzadas de DB, es simple y rápido. PHP, al ser un lenguaje dinámico, hace que procesar datos sea muy fácil. Por lo tanto, normalmente tiene sentido usar PHP.
"MySQL apesta al usar técnicas avanzadas de BD" ... es una afirmación audaz, ¿puede proporcionarnos algunos datos estadísticos o ejemplos? ... también cuando dices "normalmente tiene sentido usar PHP" ... ¿puedes decirme cuándo tiene sentido NO usar PHP? –
¿Qué quiere decir con "técnicas avanzadas de DB"? ¿Qué técnicas avanzadas de bases de datos MySQL no proporciona? –
Mi Punto de vista, incluso no tener mucha experiencia en el desarrollo de aplicaciones de gran tamaño es escribir la lógica de negocio en el PP por algunas razones:
1 - Capacidad de mantenimiento, creo que las lenguas desaprueban funciones y cambios en muchas otras cosas en un corto Por lo tanto, si PHP cambia la versión, deberá adaptar su código a la nueva versión
2 - Los DB tienden a ser más estables en el idioma, por lo que cuando sale una nueva versión de un RDBMS, generalmente no lo hace Cambia muchas cosas en la forma en que escribes tus consultas o SP, o incluso no cambia. Escribir su lógica en DB reducirá la adaptación del código debido a una nueva versión de DB
3 - Un RDBMS es más probable que esté vivo durante un período prolongado en lugar de un lenguaje de programación. Además, como sus datos son críticos, los desarrolladores de RDBMS se preocupan mucho por la migración automática de sus datos completos a la nueva versión de RDBMS, incluidos sus SP. Cuando clipper murió, no había formas de migrar los sistemas a un nuevo lenguaje de programación, tuvieron que ser completamente reescritos.
4 - Si algún día piensa cambiar por completo el idioma en el que está escribiendo la aplicación (por ejemplo, muerte del lenguaje), lo único que se reescribirá será la presentación y las llamadas SP, no la lógica comercial.
Me gustaría saber de otras personas aquí si lo que indiqué tiene sentido, y si no, por qué. Estoy en la misma situación que Sabeen Malik, estoy pensando en comenzar mi primer gran proyecto y estoy tendiendo a los SP por lo que escribí. Así que es hora de corregir mi POV si no es tan correcto.
¿Se puede cuantificar la tasa de solicitud que está pensando? –
Digamos que 100.000 visitas a la página al día –