Por que os bancos de dados não estão integrados como um recurso de idioma?

Existem linguagens de programação que possuem um banco de dados interno como um recurso de linguagem de primeira classe em vez de se conectar a um banco de dados SQL (ou outro) externo? Quais seriam as desvantagens e benefícios de tal recurso? Como seria esse recurso e como mudaria a maneira como programamos?

A única linguagem em que consigo pensar são as antigas linguagens xBase, como DBase, Clipper e FoxPro. Existe um projeto GNU que oferece uma versão gratuita e principalmente compatível chamada Clip

Também foi o Pick Basic, que vinculou uma linguagem de programação diretamente a uma plataforma de banco de dados.

Isso foi feito. Era um beco sem saída evolutivo que limitava como uma linguagem poderia acessar dados.

Os idiomas são "pequenos" e os bancos de dados são "grandes"; portanto, sempre que os dois são combinados, não é um idioma com o banco de dados como um recurso, mas um banco de dados com o idioma como um recurso. Muitos bancos de dados possuem algumas linguagens proprietárias, como PL / SQL, T-SQL.

Eu não acho necessariamente que a pergunta certa seja "por que não existe?" mas "por que deveria haver?". O que seria obtido com os bancos de dados como um recurso do idioma? Lembre-se de que a linguagem está na parte inferior da pilha de programação. Fazer um idioma inchar afeta tudo . Assim, os designers de linguagem precisam ser lentos para adicionar novos recursos, especialmente aqueles que envolvam esse investimento.

Existem três sistemas legados que estão próximos dos seus requisitos:

1. Pick ,
2. MUMPS ,
3. Microsoft Access

Pick e MUMPS foram desenvolvidos anos antes do primeiro trabalho acadêmico sobre bancos de dados relacionais (cerca de uma década antes do primeiro sistema comercial de banco de dados baseado em SQL chegar ao mercado - de uma empresa que hoje chamamos de Oracle; a primeira tentativa da IBM de um produto fracassou e um sistema baseado em SQL de sucesso foi mais tarde). Você pode encontrá-los ainda em uso (nosso sistema de transporte público local usou Pick até recentemente para o sistema de planejamento de viagens). Você não quer nada com Pick ou MUMPS, e o melhor conselho que posso dar é "afastar-se do teclado com as mãos no ar!" Se você fazer tem nada a ver com eles, a frase "você vai se arrepender" deve ser um zumbido nos ouvidos.

O Microsoft Access é severamente ridicularizado e criticado nos círculos de TI, pois é muito fácil para um não desenvolvedor criar um aplicativo comercial crítico fora do Access e transformá-lo em algo que a empresa literalmente não pode viver sem. Também é bastante provável que alguns desenvolvedores tenham começado a desenvolver via MS Access e, à medida que as coisas continuavam atoladas, eles aprenderam a corrigi-los (a primeira etapa é tradicionalmente aprender visual basic e reescrever o aplicativo Access primeiro no VB, depois em algo "melhor"). É possível criar um aplicativo do Access bem comportado que seja distribuído com uma enorme quantidade de dados - eu já vi isso - mas existem maneiras mais fáceis de fazer as coisas e é preciso muito menos habilidade para fazer (e manter) um bem aplicativo comportado fora do VB e SQL Server.

Desde o SQL Server 2005, a Microsoft introduziu a capacidade de colocar o CLR em procedimentos e funções armazenados. E, se você quiser ser complicado, pode criar tipos de dados que podem ser usados ​​como colunas no banco de dados. Eu acho que a Oracle teve algo semelhante ao Java.

Dito isto, não acho que exista algo que o impeça de criar um ou de fazer hipóteses sobre eles. Pick e MUMPS são mais antigos que a maioria dos codificadores aqui e refletem uma maneira muito COBOLy de olhar o mundo.

Meu conselho pessoal é manter as coisas separadas. Use uma linguagem que seja boa para manipular os dados que o seu projeto precisa (com a ressalva de que às vezes a melhor linguagem é aquela que você pode encontrar facilmente programadores que podem ler / escrever o código). Use um sistema de banco de dados que seja bom em manter os dados que seu projeto precisa.

Adicionar banco de dados a uma linguagem de programação pode atender apenas a um conjunto muito restrito de usuários. E se eles quiserem usar alguns recursos que não sejam RDBMS? Ou não quer usar um banco de dados? O compilador será desnecessariamente inchado para esses casos de uso.

Errar.

Bem, primeiro, você está perguntando por que a estrutura em que a linguagem opera não fornece um banco de dados. Uma linguagem é simplesmente um meio de expressar algo que você deseja que seja feito em gramáticas definidas; realmente não fornece serviços como esse. :)

Dito isto, há várias razões.

• Criar um sistema eficiente de armazenamento de banco de dados é um problema difícil, provavelmente da ordem de ou superior à criação do .NET Framework (por exemplo). Se uma equipe tentasse incluir um banco de dados em sua estrutura, isso seria tudo em que eles acabariam trabalhando.

• Um banco de dados que recebe carga deve estar em sua própria máquina separada e não no processo do código que está acessando.

• Os ORMs fornecem muito do tipo segurança e verificação de tempo de compilação que seriam o benefício de uma ação, sem que a estrutura tentasse realmente ser um banco de dados.

Dito isso, acho que seria legal incluir algum tipo de implementação SQLite na estrutura em que aplicativos com menores necessidades de acesso a dados pudessem operar. Não tenho certeza se seria útil em aplicativos não triviais, no entanto.

eles são; esses idiomas são chamados de 4GLs . O DataFlex é o meu favorito, embora eu não o use mais.

Advertência: ajudei a desenvolver a versão orientada a objetos do DataFlex, v3.0

Eu acho que sua pergunta real é "por que não existem linguagens de programação que acompanham as bibliotecas de banco de dados "?

Linguagens de uso geral tratam todas as E / S como uma e a mesma coisa, seja gravando ou lendo de / para um disco, uma webcam, a rede, a tela, um local na memória - é tudo E / S, e é isso que as linguagens de programação se preocupam com.

De fato, além da leitura / gravação no heap and stack, a maioria das linguagens de programação nem sequer realiza IO. Alguns idiomas fornecem recursos nativos para expressar operações de E / S (por exemplo, o print comando no BASIC), mas a maioria dos idiomas os trata como chamadas de função normais (por exemplo, printfem C) e permite que as bibliotecas manejem a escrita real.

Alguns idiomas, como o C #, oferecem recursos de idioma para expressar consultas, mas, mesmo assim, são apenas expressões na estrutura de dados mais básica das listas (ou IEnumerables, como são chamadas no .NET) que são traduzidas para operações SQL pelas bibliotecas - a própria linguagem ainda está apenas trabalhando com noções muito abstratas de IO.

Quanto ao motivo pelo qual construir um pacote de banco de dados na biblioteca padrão de uma linguagem de programação não é uma boa idéia, é mais provável que nada mais em uma biblioteca padrão normalmente dependa da funcionalidade do banco de dados.

Sim. Os idiomas na plataforma AS / 400 têm suporte nativo de primeira classe aos bancos de dados.

Isso ocorre porque a plataforma AS / 400 possui o banco de dados totalmente integrado em todos os lugares e permite muitos recursos muito interessantes, como facilidade de navegação em um conjunto de resultados, atualizando os valores no caminho.

Depende do idioma e da plataforma. Por exemplo, é bastante trivial para mim usar uma variedade de bancos de dados enquanto trabalho com C, apenas uso a biblioteca apropriada.

Uma linguagem deve manter sua implementação padrão, e isso normalmente significa fornecer a quantidade mínima necessária para que alguém possa construir o que quiser. Tudo o resto se torna uma biblioteca, ou talvez uma extensão da linguagem mantida por outros.

Pelo menos, esse é o caso de idiomas que seguem padrões estabelecidos por organizações como a ISO.

Como está escrito, a pergunta está parcialmente errada, como alguns contra-exemplos acima mostraram.

Então, primeiro refino a pergunta para ler: "Por que um DBMS geralmente não é integrado como um recurso de linguagens de programação de alto nível e de uso geral?"

É pelo mesmo motivo que outros produtos de software, como sistemas operacionais, sistemas de arquivos, servidores da web, camadas de cache etc. geralmente não são integrados. As linguagens de uso geral geralmente operam em um nível de abstração acima do de tais produtos. Portanto, é razoável que um programador implemente um DBMS nouma linguagem de uso geral e que o DBMS pode até expor aspectos de sua linguagem pai ou de uma linguagem declarativa específica do DB para uso dos programadores de DB. Mas há muitas opções de design ao escrever um DBMS para que seja sensato corrigi-las em uma linguagem de programação de uso geral. Se você corrigi-los, você encerra um caso como o MUMPS, em que o emaranhado dos dois resulta em um setor inteiro envolvido em um problema de galinha e ovo, preso a um DBMS obsoleto e a uma linguagem de programação obsoleta.

Utilizado para trabalhar no NonStop / SQL totalmente integrado ao NonStop / C, NonStop / C ++, NonStop / Cobol, NonStop / Fortran e provavelmente outros idiomas, além de estar totalmente integrado ao NonStop / Guardian, o sistema operacional no qual os computadores correu.

Acho que essa é provavelmente a integração mais próxima que você pode obter, onde o banco de dados É o sistema de arquivos do sistema operacional. Também é um beco sem saída, não há como desacoplar nenhum dos componentes, o banco de dados, o sistema operacional, o hardware e qualquer software escrito nele nunca podem ser usados ​​separadamente, portados para outro ambiente.

O mais próximo que você vai chegar de um PC provavelmente seria o MS Access, sendo Embarcadero / Borland Delphi um segundo próximo.

Depois disso, você está analisando bancos de dados incorporados em seu aplicativo, que podem ter apelo limitado para aqueles que criam aplicativos independentes que precisam de um conjunto de dados hierárquicos que não sejam facilmente armazenados em um arquivo de configuração simples e / ou que precisam ser atualizados regularmente conforme o aplicativo é executado. . Ou para pessoas que desejam ter uma versão portátil de um aplicativo que mantém um instantâneo de parte de um banco de dados maior e talvez sincronize com o banco de dados maior nos momentos em que o aplicativo pode fazer a conexão (útil, por exemplo, para um vendedor que geralmente está fora do alcance de a rede corporativa ainda precisa de dados de vendas para seu grupo de clientes ou um médico da área que deseja registros de pacientes, mas não pode se conectar à rede do hospital, porque não há acesso à rede para onde ele deve ir).

Como ex-desenvolvedor do Visual Foxpro, acho estranho que nenhuma linguagem convencional defina o modelo relacional como parte da linguagem.

Ter o mecanismo de banco de dados completo não é uma boa ideia, mas ter a linguagem "SQL" pode ser MUITO útil.

No OO, existe a incompatibilidade de impedância. Isso aconteceu porque os objetos e o conjunto não se parecem. Mas se uma linguagem, deixe-me definir TABLES, FIELDS, RELATIONS, CONSTRAINS, etc (sem vinculá-la a um armazenamento específico) será muito poderosa. Além disso, fazer um ORM será mais mapeamento 1 para 1.