database - soporta - optimizar consultas mysql explain

¿Por qué no debería dar acceso a personas de afuera a mi base de datos? (10)

Muchos de los sitios actuales tienen API que permiten a los usuarios obtener datos del sitio como XML o JSON utilizando una solicitud HTTP GET. Flickr y del.icio.us son ejemplos de sitios con API. Estas API requieren que el servidor acceda a la base de datos, y luego generan el resultado como XML o JSON.

¿Por qué necesitamos esta traducción? ¿Por qué no simplemente crear un usuario en la base de datos (por ejemplo, MySQL)? El usuario tendrá acceso limitado a la base de datos, solo se le permitirá SELECCIONAR, y solo ciertas tablas y ciertas columnas en esas tablas. ¿No sería esto mucho más eficiente para el servidor (no tendría que tratar con la solicitud HTTP), y sería más fácil para los desarrolladores, que ahora podrían acceder exactamente a los datos que necesitan, de la manera en que lo necesitan.

¿Puede evitar que un individuo malintencionado genere una consulta SQL súper compleja que vinculará la CPU de su base de datos al 100%? ¿Puede evitar que muchos programadores inocentes elaboren consultas ineficaces que nunca se optimizarán y que harán lo mismo?

API es un tipo de Wrapper alrededor de la base de datos. Los usuarios no saben nada sobre la representación interna de datos de la base de datos, solo necesita enviar un número de solicitudes unificadas y obtener una respuesta unificada en él. Cómo y cuándo se procesarán los datos en el servidor; no es su dolor de cabeza.

Consideraciones de seguridad aparte, para que pueda cambiar la estructura de su base de datos sin afectar a sus clientes. Además, las consultas mal formadas vinculan a su servidor, no a los clientes.

La seguridad es la razón número 1, pero espero que esas razones sean obvias. El usuario que bloquea recursos valiosos con malas consultas es otra buena razón.

Más allá de eso, ¿por qué una capa de abstracción?

¿Alguna vez podría querer agregar un poco de registro a las consultas de la base de datos para diagnosticar la velocidad o ayudar a la depuración?
¿Alguna vez podría pasar de MySQL a MS SQL o viceversa donde SQL aparte de puro ANSI podría romperse?
¿El cliente realmente debe aprender su esquema en lugar de una abstracción más lógica?
Cuando un nuevo programador se entera de la normalización y ahora puede ver su esquema completo, incluidas sus desnormalizaciones cuidadosamente equilibradas, ¿quiere soportar todas las críticas desinformadas?
Cuando una persona db con más experiencia señala mejoras, ¿quiere quedarse con su viejo esquema?

Por qué usar una API es una cuestión de por qué usar abstracciones y mi lista aquí apenas araña la superficie.

Lo que debe tener en cuenta cuando piensa en cuestiones de seguridad es que es realmente difícil anticipar todos los vectores posibles que alguien podría usar para atacarlo. Por ejemplo, ¿ está seguro de que ha configurado los permisos de su base de datos para que las personas no puedan estropear las cosas?

Por lo tanto, debes intentar restringir las acciones solo a lo que sabes que es bueno, no solo tratar de restringir las cosas que sabes que son malas. Esto se puede hacer con un servicio web sobre el que tenga control absoluto, pero es difícil permitir que alguien acceda directamente a la base de datos y asegurarse de que esté seguro.

No es tanto un ''por qué no'' como un ''por qué deberías'' hacer una pregunta. El manejo de las solicitudes HTTP es una pequeña penalización para tener un control completo sobre a qué información le permite o no permite el acceso de un usuario. Además, si el nivel de cantidad / seguridad / naturaleza de los datos cambia en el futuro, estará mejor con una respuesta JSON / XML que permitiendo el acceso total.

Portabilidad también Digamos que por razones de licencia y escalamiento, usted toma la decisión comercial de pasar de MSSQL a MySql. La sintaxis no es la misma y tus clientes tendrán que cambiar su código.

Es mucho mejor simplemente amortiguar todo y mantener la implementación abstraída. ¿De quién decir que no está persistiendo en el estado de la aplicación usando monos entrenados rascando marcas en las tapas de botellas?

Una API:

Hace que sea más fácil acumular y controlar el uso (la implementación de ''consultas limitadas por X'' para los usuarios de DB puede ser más difícil)
Permite presentar estructuras más simples para el usuario que las que se pueden usar en la base de datos.
Significa que el usuario no tiene que entender su estructura de base de datos.
Permite la portabilidad de DB. (Oh, has crecido enormemente y ahora necesitas implementar: sharding, move to bigtable, etc. - Con una API, el usuario no necesita saber)
Permite diferentes caché de solicitudes (¿mejor? / ¿Variable?).
Significa que no tiene que pagar por usuarios adicionales de BD (si así es como se licencia la base de datos).

el servidor web le proporciona un búfer que puede controlar. si hay algún error en su servidor sql o lo que sea, no quiere que se exponga directamente a internet. es cierto, si el servidor web tiene errores, podría ser igual de malo ... excepto que tienes esa capa adicional entre los datos y el mundo.

-don

Codificación por contrato : con las API, puede cambiar todo lo que hay detrás de ellas sin afectar el uso por parte de terceros de ellas. Aquí los estarías atando no solo a MySQL sino a tu esquema

Almacenamiento en caché : permitirles cualquier consulta casi elimina cualquier oportunidad de almacenamiento en memoria caché de las consultas predecibles sobre http que se pueden usar. Esta es probablemente la forma principal de eliminar el cuello de botella a menudo número uno, la base de datos.

Seguridad : con este enfoque, sería fácil para un ataque de denegación de servicio, incluso por accidente. Sin mencionar el hecho de que tendrías que dar acceso a la capa de datos, que a menudo se coloca en una zona restringida donde la seguridad se puede ajustar

Usabilidad : no todos son desarrolladores o desean comprender un dominio interno. Probablemente prefieran una API predefinida y autoexplicativa. Un ejemplo extremo sería dar a los administradores privilegios de db en lugar de informes.