¿Por qué las bases de datos no están integradas como una función de idioma?

¿Hay algún lenguaje de programación que tenga una base de datos integrada como una función de lenguaje de primera clase en lugar de conectarse a una base de datos SQL externa (u otra)? ¿Cuáles serían los inconvenientes y los beneficios de tal característica? ¿Cómo sería esa característica y cómo cambiaría la forma en que programamos?

El único lenguaje en el que puedo pensar es en los antiguos lenguajes xBase como DBase, Clipper y FoxPro. Hay un proyecto GNU que ofrece una versión gratuita y en su mayoría compatible llamada Clip

También fue Pick Basic, que vinculaba un lenguaje de programación directamente a una plataforma de base de datos.

Esto ha sido hecho. Fue un callejón sin salida evolutivo que limitó la forma en que un idioma podía acceder a los datos.

Los idiomas son "pequeños" y las bases de datos son "grandes"; así que cada vez que se combinan los dos, no es un lenguaje con la base de datos como características, sino una base de datos con el idioma como característica. Muchas bases de datos tienen algunos lenguajes patentados, por ejemplo, PL / SQL, T-SQL.

No creo necesariamente que la pregunta correcta sea "¿por qué no están allí?" pero "¿por qué debería haber?". ¿Qué se ganaría si las bases de datos fueran una característica del lenguaje? Recuerde, el lenguaje está en la parte inferior de la pila de programación. Hacer que un idioma se hinche afecta todo . Por lo tanto, los diseñadores de idiomas deben ser lentos para agregar nuevas funciones, especialmente las que implicarían tal inversión.

Hay 3 sistemas heredados que están cerca de sus requisitos:

1. Recoger ,
2. PAPERAS ,
3. acceso Microsoft

Pick y MUMPS se desarrollaron años antes del primer artículo académico sobre bases de datos relacionales (que fue aproximadamente una década antes de que el primer sistema de base de datos comercial basado en SQL llegara al mercado, de una compañía que ahora llamamos Oracle; el primer intento de IBM de un producto fracasó y un sistema basado en SQL exitoso fue más tarde). Es posible que los encuentre todavía en uso (nuestro sistema de transporte público local utilizó Pick hasta hace poco para el sistema de planificación de viajes). No quiere tener nada que ver con Pick o MUMPS, y el mejor consejo que puedo dar es "¡aléjese del teclado con las manos en el aire!" Si tu lo tiene nada que ver con ellos, la frase "Te arrepentirás" debe ser un zumbido en los oídos.

Microsoft Access es severamente burlado y criticado en los círculos de TI, ya que es bastante fácil para un no desarrollador crear una aplicación comercial crítica de Access y hacer que mute en algo que la compañía literalmente no puede vivir. También es muy probable que algunos desarrolladores hayan comenzado a desarrollar a través de MS Access y, a medida que las cosas se estancaban, aprendieron a solucionarlos (el primer paso es aprender tradicionalmente visual basic y reescribir la aplicación Access primero en VB, luego en algo "mejor"). Es posible hacer una aplicación de Access que se comporte bien y que se distribuya con una gran cantidad de datos, lo he visto hecho, pero hay formas más fáciles de hacer las cosas, y se necesita mucha menos habilidad para hacer (y mantener) un pozo aplicación comportada fuera de VB y SQL Server.

Desde SQL Server 2005, Microsoft ha introducido la capacidad de poner CLR en procedimientos y funciones almacenados. Y si quieres ser complicado al respecto, puedes crear tipos de datos que luego puedas usar como columnas en la base de datos. Creo que Oracle ha tenido algo similar con Java.

Dicho esto, no creo que haya nada que te impida crear uno o hipotetizar sobre ellos. Pick y MUMPS son más antiguos que la mayoría de los codificadores aquí y reflejan una manera muy COBOL de mirar el mundo.

Mi consejo personal es mantener las cosas separadas. Utilice un lenguaje que sea bueno para manipular los datos que su proyecto necesita (con la advertencia de que a veces el "mejor" lenguaje es el que puede encontrar fácilmente programadores que pueden leer / escribir el código). Use un sistema de base de datos que sea bueno para mantener los datos que su proyecto necesita.

Agregar una base de datos a un lenguaje de programación puede atender solo a un conjunto muy limitado de usuarios. ¿Qué pasa si quieren usar algunas características que no son RDBMS? ¿O no quieres usar una base de datos? El compilador se hinchará innecesariamente para tales casos de uso.

Errar.

Bueno, primero, se pregunta por qué el marco en el que opera el lenguaje no proporciona una base de datos. Un lenguaje es simplemente un medio de expresar algo que desea que se haga en gramática establecida; Realmente no proporciona servicios como ese. :)

Dicho esto, hay varias razones.

• Construir un sistema de almacenamiento de base de datos eficiente es un problema difícil, probablemente del orden o mayor que construir el .NET Framework (por ejemplo). Si un equipo intentara incluir una base de datos en su marco, eso sería todo en lo que terminarían trabajando.

• Una base de datos que recibe carga debe estar en su propia máquina separada y no en el proceso del código que está accediendo a ella.

• Los ORM proporcionan una gran cantidad de seguridad de tipo y verificación de tiempo de compilación que sería el beneficio de tal acción, sin que el marco intente ser una base de datos.

Dicho esto, supongo que sería bueno incluir algún tipo de implementación de SQLite dentro del marco en el que las aplicaciones con menores necesidades de acceso a datos podrían operar. Sin embargo, no estoy seguro de que sea útil en aplicaciones no triviales.

son; tales lenguajes se llaman 4GL . DataFlex es mi favorito, aunque ya no lo uso.

Advertencia: ayudé a desarrollar la versión orientada a objetos de DataFlex, v3.0

Creo que su pregunta real es "¿por qué no hay lenguajes de programación que vienen con las bibliotecas de bases de datos? "?

Los lenguajes de propósito general tratan a todos los IO como uno solo, ya sea escribiendo o leyendo desde / a un disco, una cámara web, la red, la pantalla, una ubicación en la memoria: todo es IO, y eso es todo lo que se preocupan por los lenguajes de programación con.

De hecho, aparte de leer / escribir en el montón y la pila, la mayoría de los lenguajes de programación ni siquiera hacen ningún IO real. Algunos lenguajes proporcionan características nativas para expresar operaciones de E / S (p. Ej., El print comando en BASIC), pero la mayoría de los lenguajes los tratan como llamadas a funciones normales (p. Ej. printfEn C) y permiten que las bibliotecas manejen la escritura real.

Algunos lenguajes como C # ofrecen características de lenguaje para expresar consultas, pero aun así, esas son solo expresiones en la estructura de datos más básica de las listas (oIEnumerable s, como se llaman en .NET) que las bibliotecas traducen a operaciones SQL. el lenguaje en sí sigue trabajando con nociones muy abstractas de IO.

En cuanto a por qué construir un paquete de base de datos en la biblioteca estándar de un lenguaje de programación no es una buena idea, lo más probable es que nada más en una biblioteca estándar dependería normalmente de la funcionalidad de la base de datos.

Sí. Los idiomas en la plataforma AS / 400 tienen soporte nativo de primera clase para bases de datos.

Esto se debe a que la plataforma AS / 400 tiene la base de datos totalmente integrada en todas partes y permite muchas características muy buenas, como la facilidad de navegación a través de un conjunto de resultados que actualiza los valores en el camino.

Depende del idioma y la plataforma. Por ejemplo, es bastante trivial para mí usar una variedad de bases de datos mientras trabajo con C, solo uso la biblioteca apropiada.

Un lenguaje debe mantener su implementación estándar, y eso generalmente significa proporcionar la cantidad mínima necesaria para que alguien pueda construir lo que quiera construir. Todo lo demás se convierte en una biblioteca, o quizás en una extensión del lenguaje que mantienen otros.

Al menos, este es el caso de los idiomas que siguen los estándares establecidos por organizaciones como ISO.

Tal como está escrito, la pregunta es en parte incorrecta, como han mostrado algunos contraejemplos anteriores.

Así que primero refinaría la pregunta para leer: "¿Por qué un DBMS generalmente no está integrado como una característica de un lenguaje de programación de alto nivel y propósito general?"

Esto es por la misma razón que otros productos de software, como sistemas operativos, sistemas de archivos, servidores web, capas de almacenamiento en caché, etc., generalmente no están integrados. Los lenguajes de uso general generalmente operan a un nivel de abstracción superior al de dichos productos. Por lo tanto, es razonable que un programador implemente un DBMS, enun lenguaje de propósito general, y ese DBMS podría incluso exponer aspectos de su lenguaje principal o un lenguaje declarativo específico de DB para uso de los programadores de DB. Pero hay demasiadas opciones de diseño al escribir un DBMS para que sea prudente arreglarlo en un lenguaje de programación de propósito general. Si los soluciona, terminará con un caso como MUMPS, donde el enredo de los dos resultados en una industria entera sumida en un problema de huevo y gallina, atrapado con un DBMS obsoleto y un lenguaje de programación obsoleto.

Solía ​​funcionar en NonStop / SQL, que estaba completamente integrado en NonStop / C, NonStop / C ++, NonStop / Cobol, NonStop / Fortran y probablemente otros idiomas, además de estar completamente integrado con NonStop / Guardian, el sistema operativo en el que las computadoras corrió.

Creo que esa es probablemente la integración más cercana que puede obtener, donde la base de datos ES el sistema de archivos del sistema operativo. También es un callejón sin salida, no hay forma de desacoplar ninguno de los componentes, la base de datos, el sistema operativo, el hardware y cualquier software escrito en él nunca se puede usar por separado, portado a otro entorno.

Lo más cercano que vas a tener en una PC probablemente sea MS Access, Embarcadero / Borland Delphi en segundo lugar.

Después de eso, está buscando bases de datos integradas en su aplicación, que pueden tener un atractivo limitado para aquellos que crean aplicaciones independientes que necesitan un conjunto de datos jerárquicos que no se almacenan fácilmente en un archivo de configuración simple y / o necesitan una actualización regular a medida que la aplicación se ejecuta . O para las personas que desean tener una versión portátil de una aplicación que mantenga una instantánea de parte de una base de datos más grande y tal vez la sincronice con la base de datos más grande en momentos en que la aplicación puede hacer la conexión (útil, por ejemplo, un vendedor que a menudo está fuera del alcance de la red corporativa aún necesita datos de ventas para su grupo de clientes, o un médico en el campo que quiere registros de pacientes pero no puede conectarse a la red del hospital porque no hay acceso a la red a donde tiene que ir).

Como ex desarrollador de Visual Foxpro, creo que es extraño que ningún lenguaje convencional defina el modelo relacional como parte del lenguaje.

Tener el motor de base de datos completo no es una buena idea, pero tener el lenguaje "SQL" podría ser MUY útil.

En OO, existe la falta de coincidencia de impedancia. Esto sucedió porque los objetos y el conjunto no se parecen entre sí. Pero si un lenguaje me permite definir TABLAS, CAMPOS, RELACIONES, RESTRICCIONES, etc. (sin vincularlo a un almacenamiento en particular) será muy poderoso. Además, hacer un ORM será más un mapeo 1 a 1.