¿Qué debo considerar en el diseño de base de datos para una nueva aplicación que debería ser capaz de soportar los sistemas de bases de datos relacionales más comunes (SQL Server, MySQL, Oracle, PostgreSQL ...) ?Diseño de base de datos para aplicaciones agnósticas de base de datos
¿Vale la pena el esfuerzo? ¿Cuáles son las trampas?
La respuesta corta es ceñirse a las características que están estándar o cerca de implementarse de manera estándar. Lo que esto significa en más detalle es:
evitar cualquier cosa que utiliza un lenguaje procesal de la base de datos (procedimientos almacenados o disparadores) ya que es donde las enormes diferencias entre los sistemas vienen en Es posible que necesite utilizarlos para emular. algunas funciones, pero no las use para crear su propia funcionalidad.
Separar automáticamente las secuencias de campos de los propios campos. Esto se verá un poco forzado para MSSQL, pero se implementará limpiamente en Oracle, DB/2, etc., sin necesidad de correcciones de emulación.
Mantiene los campos char y varchar por debajo del tamaño máximo más pequeño para el conjunto de motores que pretendes.
Cuando está escribiendo consultas, use la sintaxis JOIN completa, y ponga en corchete las UNIONES para que cada unión se encuentre entre una sola tabla y una expresión entre corchetes.
Mantenga la lógica de manejo de fechas en el código, no en las consultas, ya que muchas de las funciones de fecha están fuera del estándar. (Por ejemplo:. Si desea obtener cosas para las últimas dos semanas calcular la fecha hace dos semanas en el código y el uso que en la consulta)
Más allá de que el esfuerzo no debe ser demasiado intimidante, por lo que bien puede valer la pena.
O bien, utilizar una tecnología de persistencia como Hibernate/NHibernate que abstrae las diferencias entre los diferentes DBs.
Mantenga los nombres de campo y tabla cortos (< 30 caracteres) y no distingue entre mayúsculas y minúsculas. p.ej. TABLE_NAME y FIELD_NAME
95% portable es casi tan bueno como portátil si puede aislar el código dependiente de la plataforma en una capa específica. Así como Java se ha descrito como 'Write once test everywhere', todavía se debe probar la aplicación en cada plataforma en la que se quiera ejecutar.
Si es prudente con el código específico de su plataforma, puede usar un código portátil para el 95% de la funcionalidad que se puede hacer adecuadamente de forma portátil. Las partes restantes que deben realizarse en un procedimiento almacenado u otra construcción dependiente de la plataforma se pueden integrar en una serie de módulos dependientes de la plataforma a una interfaz estándar. Dependiendo de la plataforma, usa el módulo apropiado para esa plataforma.
Esta es la diferencia entre 'Prueba en todas partes' y 'Desarrollar módulos específicos de plataforma y Prueba en todas partes'. Deberás probar en todas las plataformas compatibles de todos modos, no puedes escapar de eso. La construcción extra es relativamente menor, y probablemente menos que hacer una arquitectura realmente intrincada para tratar de hacer estas cosas de manera totalmente portátil.
Actualmente soporto Oracle, MySQL y SQLite. Y para ser honesto, es difícil. Algunas recomendaciones serían:
procedimientosVale la pena ... bien depende. Comercialmente vale la pena para las aplicaciones de nivel empresarial, pero para un blog o decir un sitio web, es mejor que se quede con una plataforma si puede.
Me gusta la sugerencia de desencadenantes –
No es tan difícil rodar su autoincrement –
+1 para evitar procs y utilizar un entorno de prueba decente para asegurarse de que su aplicación en realidad * es * DB independiente del agnóstico; No estoy de acuerdo con el uso de desencadenantes, y prefiero usar una estrategia de asignación de ID que también es DB agnostic. – Brian
Una respuesta que la gente a menudo le dirá es no usar el sql específico de la base de datos y simplemente codificar para los estándares ansi. A menudo dirán que solo hablan con la base de datos a través de procs almacenados para abstraer cualquier sql. Estas son las respuestas incorrectas y solo conducen al dolor. La codificación de sql 'estándar' es bastante imposible porque cada vendedor tiene interpretaciones diferentes.
Lo que necesita es tener algún tipo de capa de persistencia de base de datos los resúmenes de las diferencias entre las bases de datos (lo siento, johnstock, esto es casi exactamente lo que ha dicho).Hay muchos otros ORM y productos similares para hacer esto para cada plataforma,
También es difícil codificar SQL estándar, dado que la mayoría, si no todos, los DBMS comerciales no son compatibles con el 100% de las características del ANSI estándar. La respuesta más práctica es codificar el subconjunto de SQL que se admite en todas las plataformas que le interesan. Es decir, encontrar la intersección, en el sentido de la teoría de conjuntos, de sus implementaciones. – Jay
El problema es que Jay, una vez que ha encontrado el subconjunto de funcionalidad que es común entre los proveedores, todo lo que le queda son instrucciones muy básicas SELECT, INSERT, UPDATE. – Craig
@Crag, SQL debe considerarse de primera clase en su aplicación. Enterrarlo en el cliente y el código ORM es una pesadilla que la mayoría puede atestiguar. Resumen de las funciones de DB a través de procedimientos y vistas es un concepto casi universal. – Xailor
Si yo fuera usted, me gustaría pensar mucho sobre el rendimiento de su inversión aquí.
Suena suena como una gran idea para poder conectar cualquier parte trasera o cambiar los extremos cuando quiera, pero esto rara vez ocurre en el mundo real en mi experiencia.
Es posible que cubra el 95% de sus clientes potenciales al admitir solo Oracle & SQL Server (o MySQL & SQL Server, o ... etc.).
Investigue antes de seguir adelante, ¡y buena suerte!
Tiene razón, rara vez sucede con aplicaciones de tipo empresarial, pero es bastante común para el software de tipo retráctil. Por ejemplo, actualmente estoy desarrollando y la herramienta ETL que utilizamos en muchos sitios de clientes. Necesita trabajar con Oracle y SQL Server y posiblemente más en el futuro. – Craig
Voy a plagerizar la respuesta de johnstok de 1) No use procedimientos almacenados y 2) No use SQL específico del vendedor y añádalo.
También preguntó: "¿Vale la pena el esfuerzo?". Yo diría ... tal vez. Escribí un rastreador de errores de código abierto, BugTracker.NET, que está basado en SQL Server. Hay muchos desarrolladores que simplemente no lo probarán porque les gusta apegarse a las tecnologías con las que se sienten cómodos. Y, cuando estaba considerando comenzar un servicio de alojamiento, noté que los servidores virtuales dedicados de Linux son mucho más baratos que los servicios de Windows (no virtuales). Teóricamente podría ejecutar el C# en mono, pero mi SQL es tan específico de SQL Server (aunque no utilizo procs almacenados) sería un gran esfuerzo de puerto.
Si se dirige a un mercado empresarial/corporativo, descubrirá que algunas tiendas son estrictamente Oracle, o estrictamente SQL Server, y que su aplicación podría descartarse en las primeras rondas de la competencia en función de la tecnología que usos.
Por lo tanto, tal vez ser abierto sí importa, para usted. ¿Qué tipo de aplicación es? ¿Quién lo usará?
También preguntó: "¿Qué son los ptifalls". No probando sobre la marcha. Si planeas respaldar los 4 dbs que enumeró, entonces deberías probarlos con anticipación y con frecuencia, en lugar de solo enfocarte en uno, mientras piensas que será fácil convertirlo a los demás. Para entonces, es posible que se encuentre en un callejón sin salida arquitectónico.
Investigue por adelantado el denominador común más bajo para los tipos de datos. Por ejemplo, SQL Server tiene un número entero pero Oracle usa un número.
Entiendo las otras respuestas aquí, pero ¿por qué no utilizar procedimientos almacenados? ¿Es así que la lógica no está oculta?
Compara y contrasta, digamos, T-SQL (Sybase, MS SQL) y PL/SQL (Oracle). Entonces sabrás. :) Pero pensándolo bien, a lo largo de los años he llegado a odiar cualquier cosa que se asemeje a la lógica de negocios que se esconde en la base de datos ... –
Ver mi comentario a continuación - tienen un lugar cuando se ven obligados a utilizar db específico construcciones –
En 2001, trabajé en un producto que tenía que soportar Oracle 8, MS SQL Server 2000 y MS Jet 3.51 (por ejemplo, Access97). En teoría, podríamos haber empleado especialistas para cada uno de estos productos y un proceso de prueba que aseguró que todos produjeran los mismos resultados. En la práctica, hubo una tendencia hacia el mínimo común denominador.
Un enfoque fue crear tablas vinculadas en Access/Jet para Oracle y SQL Server y luego escribir exclusivamente Jet SQL. El problema aquí es que la sintaxis de Jet SQL es muy limitada.
¡Otro enfoque (comúnmente empleado incluso en sistemas que solo han usado un producto DBMS!) Es intentar hacer más del trabajo que uno realmente debería en el front end, cosas que deberían ser el dominio del DBMS . El problema aquí es que a menudo es desastroso en cuanto a la integridad de los datos. Estoy seguro de que conoce la situación: la aplicación debe contener y evitar escribir datos ilegales, pero sin restricciones en el mismo DBMS está abierto a los errores de la aplicación. Y luego está el usuario que sabe cómo conectarse a los datos a través de Excel, SQL Management Studio, etc., y omitir así por completo la aplicación que se supone que garantiza la integridad de los datos ...
Personalmente, me encontré cada vez más escribiendo código en una escala móvil de lo que luego descubrí que se llamaba 'portabilidad'. Idealmente, en primera instancia es el código 'vainilla' entendido por todos los DBMS que apoyamos y al hacerlo, descubrí los estándares SQL-89 y SQL-92. Lo siguiente fue un código SQL que podría traducirse fácilmente (quizás usando código) para cada DBMS, por ej. Oracle usó esa sintaxis horrible de unión externa infija pero el concepto de unión externa estaba allí; Oracle y SQL Server usaron SUBSTRING pero Jet requirió que la palabra clave fuera MID $; etc. Por último, hay cosas que simplemente tienen que ser específicas de la implementación, obviamente evitadas si es posible mientras se sigue prestando la debida atención a la integridad de los datos, la funcionalidad y el rendimiento.
Afortunadamente, en los años transcurridos los productos se han estado acercando a los estándares ANSI SQL (aparte de Jet, que fue desaprobado por MS ahora solo se mantiene vivo por el equipo de MS Access aparentemente cortando características importantes como seguridad y replicación). Así que he mantenido el hábito de escribir SQL estándar siempre que sea posible.
Además de tener en cuenta las muchas respuestas buenas y sensatas aquí, también agregaría que algo como ActiveRecord migrations (de Ruby On Rails, pero puedes usar la biblioteca) podría ser útil. Resume cosas como la creación/alteración de tablas, los tipos de columnas apropiados, la gestión de índices más simple y (hasta cierta cantidad) la secuencia en un lenguaje descriptivo bastante simple.
Los procedimientos almacenados y desencadenantes son prácticamente ignorados, pero si se va multiplataforma, ese tipo de funcionalidad probablemente debería estar en una capa de código.
Por curiosidad he cambiado entre Oracle, MS SQL, MySQL y SQLite con el mismo conjunto de migraciones y el peor problema que tuve fue descubrir que tenía que asegurar que mis nombres de columnas y tablas no estaban en la unión de reservados listas de palabras en los DB.
Regla 1: No utilice base de datos de características
Regla 2: No utilice los procedimientos almacenados.
Regla 3: Si rompe la Regla 1, también infringe la regla 2.
Ha habido muchos comentarios sobre el uso de procedimientos almacenados. Esto se debe a que la sintaxis/semántica es muy diferente y, por lo tanto, transferirlos es difícil. No quieres montones de código que hayas reescrito y vuelto a probar.
Si decide que necesita utilizar características específicas de la base de datos, debe ocultar esos detalles detrás de un procedimiento almacenado. Llamar a los procedimientos almacenados de diferentes bases de datos es bastante similar. Dentro del procedimiento, que está escrito en PL/SQL, puede usar cualquier construcción de Oracle que le parezca útil. Luego debe escribir un equivalente para las otras bases de datos de destino. De esta manera, las partes que son específicas de la base de datos están en esa base de datos solamente.
De ser posible, evitaría hacer esto. He trabajado con varias de estas bases de datos en el pasado y fueron terriblemente lentas (un ejemplo particularmente doloroso que puedo pensar fue una aplicación de centro de llamadas que tardó diez minutos en pasar de una pantalla a otra en un día ocupado) debido a la necesidad para escribir sql genérico y no usar el ajuste de rendimiento que era mejor para el backend particular.
En complemento a this answer, y como regla general, no permita que el servidor genere o calcule datos. Envíe siempre instrucciones SQL directas, sin incluir fórmulas. No use propiedades de valor por defecto (ni las haga básicas, no fórmulas). No use las reglas de validación Tanto los valores predeterminados como las reglas de validación deben implementarse en el lado del cliente.
No votaré, pero pierde mucha velocidad y aumenta la complejidad al sacar la lógica de la base de datos. No sigamos la ruta de sugerir que ignoremos todas las características de DB (es tan 1990); es decir, la validación se puede diseñar fácilmente en SQL básico. – Xailor
Lo primero a tener en cuenta es si el costo de hacerlo de forma independiente es menor y depende de la base de datos. Creo que algunas veces es importante que algunos productos ofrezcan opciones a los clientes, pero están perdiendo muchas características de la base de datos (significa que el código debe escribirse nuevamente).
Para grandes clientes (grandes aplicaciones) tienen que depender completamente de la base de datos. Para pequeñas personalizaciones, es realmente un problema tener un Oracle XE y un MySQL en un servidor (o dos).
Realmente, prefiero usar más de una base de datos y que la aplicación sabe qué base de datos es un código "abastract".
OMI Depende del tipo de aplicación que está desarrollando:
Para el caso 1, simplemente elija un DBMS que se adapte mejor a sus necesidades, y codifique contra eso, utilizando toda la potencia de todas sus características patentadas.
Para el caso 2, probablemente encontrará que es bastante factible apegarse al subconjunto común de operaciones admitidas por todos los DBMS que pretenda admitir.
ora ¿por qué tu tabla única entre corchetes? – Xailor