Quelqu'un at-il écrit un langage de requête de niveau supérieur (que sql) qui génère sql pour les tâches courantes, sur les schémas limités

Question

Sql est le standard dans les langages de requête, mais il est parfois un peu bavard. J'écris actuellement un langage de requête limité qui rendra mes requêtes courantes plus rapides à écrire et avec un peu moins de surcharge mentale. Si vous écrivez une requête sur un bon schéma de base de données, vous joindrez toujours la clé primaire, les champs de clé étrangère, donc je pense qu'il ne devrait pas être nécessaire de les déclarer à chaque fois.

Donc, une requête pourrait ressembler.

select s.name, region.description from shop s 
where monthly_sales.amount > 4000 and s.staff < 10 

Les relations seraient

boutique - plusieurs à un - région,

boutique - un à plusieurs - monthly_sales

Le sql qui serait eqivilent à serait être

select distinct s.name, r.description 
from shop s 
join region r on shop.region_id = region.region_id 
join monthly_sales ms on ms.shop_id = s.shop_id 
where ms.sales.amount > 4000 and s.staff < 10 

(le distinct est là que vous vous joignez à un un à plusieurs table (mon thly_sales) et vous ne sélectionnez pas de champs de cette table)

Je comprends que la requête d'origine ci-dessus peut être ambiguë pour certains schémas, c'est-à-dire s'il existe deux routes de relation entre deux des tables. Cependant, il existe des moyens de contourner (la plupart) de ceux-ci, surtout si vous limitez le schéma autorisé. La plupart des schémas possibles ne valent pas la peine d'être considérés de toute façon.

Je me demandais juste s'il y avait des tentatives pour faire quelque chose comme ça? (J'ai vu la plupart des solutions d'orm à faire quelques questions plus faciles)

EDIT: En fait j'aime vraiment sql. J'ai utilisé des solutions orm et regardé linq. Le meilleur que j'ai vu jusqu'ici est SQLalchemy (pour python). Cependant, autant que j'ai vu, ils n'offrent pas ce que je cherche.

Answer 1

Mise en veille prolongée et LinqToSQL font exactement ce que vous voulez

Answer 2

Je crois que tout (décent) ORM serait d'aide ici ..

Answer 3

Entity SQL est légèrement niveau supérieur (dans des lieux) que Transact SQL. A part cela, HQL, etc. Pour des approches modèle objet, LINQ (IQueryable<T>) est de niveau beaucoup plus élevé, ce qui permet une navigation simple:

var qry = from cust in db.Customers 
      select cust.Orders.Sum(o => o.OrderValue); 

etc

Answer 4

Je pense que vous seriez mieux passer votre temps juste écrire plus de SQL et devenir plus à l'aise avec elle. La plupart des développeurs que je connais sont passés par cette progression, où leur exposition initiale à SQL les pousse à la contourner entièrement en écrivant leur propre ORM ou un ensemble de classes auxiliaires qui génère automatiquement le SQL pour eux. Habituellement, ils continuent à l'ajouter et à l'affiner jusqu'à ce que ce soit aussi complexe (sinon plus) que SQL. Les résultats sont parfois assez comiques - j'ai hérité d'une application qui avait des classes nommées "And.cs" et "Or.cs", dont les fonctions principales étaient d'ajouter les mots "AND" et "OR", respectivement, à une chaîne. SQL est conçu pour gérer une grande variété de complexité.Si la conception de données de votre application est simple, le SQL pour manipuler ces données sera également simple. Cela n'a pas beaucoup de sens d'utiliser un langage de requête différent pour des choses simples, puis d'utiliser SQL pour les choses complexes, quand SQL peut bien gérer les deux types de choses.

Answer 5

Martin Fowler a mis à l'eau toute une charge d'énergie et a produit le modèle Active Record. Je pense que c'est ce que tu cherches?

Answer 6

Je ne sais pas si cela correspond à ce que vous recherchez, mais j'ai généré dynamiquement SQL à partir de la définition des objets d'accès aux données; l'idée est de réfléchir sur la classe et par défaut supposer que son nom est le nom de la table et toutes les propriétés sont des colonnes. J'ai aussi des objets de critères de recherche pour construire la partie where. Les DAO peuvent contenir des listes d'autres classes DAO et qui dirige les jointures.

Depuis que vous avez demandé quelque chose pour prendre soin de la plupart des SQL répétitives, cette approche le fait. Et quand ce n'est pas le cas, je me contente de SQL manuscrit ou de procédures stockées.