web-dev-qa-db-fra.com

Report / SQL Builder - Conditions imbriquées

Je travaille sur un projet qui permettra à un utilisateur de créer des rapports en construisant de nombreuses règles, afin qu'ils puissent voir les données qui les intéressent. L'interface utilisateur doit être puissante mais simple. J'espère que les Balsamiq ci-dessous l'expliqueront un peu mieux que moi en utilisant des mots!

Cela commence assez simple. Vous pouvez sélectionner les champs qui vous intéressent et commencer à ajouter des règles ...

Step 1 - pretty simple!

Step 2 - adding some rules

Cela devient un peu moche quand il s'agit d'avoir une requête imbriquée. L'exemple ci-dessous: " Montrez-moi tous les utilisateurs qui ont reçu des e-mails au cours de la première semaine de mai, dont le nom de famille contient 'Smith'" .

a little icky...

Les vrais problèmes commencent lorsque nous avons des requêtes imbriquées dans des requêtes imbriquées. Ce rapport particulier (fictif, inutile ... mais vous avez l'idée!) Est "tous les utilisateurs dont le nom contient" smith ", qui n'ont jamais reçu d'e-mail de joe.bloggs@example .com, mais ont reçu un e-mail au cours de la première semaine de mai ".

oh dear.

Existe-t-il un moyen plus efficace de créer ce type d'interface utilisateur? De manière réaliste, la plupart des rapports seront assez simples, et je m'attends à ce que très peu aient 3 sous-requêtes imbriquées ou plus - mais je sais qu'il y en aura certainement certains qui en ont 3.

Contexte: une base de données qui contient les membres d'un groupe national, ~ 100 000 membres. Les utilisateurs sont répartis en niveaux régionaux. Communications/e-mails envoyés via le système.

Note technique: Les tables liées 'in/not in' seront là où une clé étrangère existe entre le champ sélectionné et une autre table. Je ne sais pas encore comment gérer les FK non uniques sur une table (par exemple, expéditeur/destinataire), et je n'ai pas encore inquiété ' ET 'vs' OU '...

formsgui-designwizard
1
Dave Salomon

J'ai fini par changer la base de données pour accueillir une interface utilisateur plus simple. Un exemple de requête imbriquée peut avoir été "Afficher toutes les régions où les données des membres n'ont pas été téléchargées au cours des 30 derniers jours". La requête ressemblerait à (pesudo):

SELECT region_name 
  FROM region
 WHERE region_id NOT IN (
    SELECT region_id
      FROM upload_history
     WHERE upload_date < DATE()-30
 )

Au lieu de cela, je viens d'ajouter un last_upload_date à la table region, et permettra à l'utilisateur de le sélectionner dans la clause 'where' à la place.

Voici l'interface utilisateur dans sa forme (presque terminée). A juste besoin d'un peu de vernis. (Couleurs, logos, etc. tous à déterminer)

The UI

Merci pour vos commentaires + assistance!

2
Dave Salomon

Cela prendrait plus de travail, mais je pense que ce serait assez simple si vous pouviez imiter le comportement dans Mac Mail lors de la recherche dans les e-mails.

Vous pouvez simplement avoir un grand champ de recherche et permettre aux utilisateurs de saisir simplement des mots clés. Par exemple, dans Mac Mail, vous pouvez taper "de: John" et il recherchera les e-mails de John.

Dans votre exemple:

"Montrez-moi tous les utilisateurs qui ont reçu des e-mails au cours de la première semaine de mai, dont le nom de famille contient" Smith ""

Vous pouvez autoriser l'utilisateur à taper quelque chose comme ceci:

mockup

télécharger la source bmml - Wireframes créés avec Balsamiq Mockups

Découvrez le comportement dans Mac Mail pour avoir une meilleure idée de la façon dont cela fonctionne.

0
kwahn