2009-09-15 5 views
0

Je développe une application de feuille de temps en utilisant SQL Server comme mon backend et j'essaie de trouver la meilleure façon de gérer l'implémentation de la logique de traitement relativement complexe dans ma base de données à des fins de reporting.Comment puis-je effectuer efficacement un traitement avancé sur ma base de données?

I ont une table (timesheet_entries) qui est composé des champs suivants:

  • entry_id

  • employe_id

  • job_id

  • job_state

  • pto_code (cela signifie que l'entrée est Payé Time Off et est l'identifiant de quel type de PTO - Vacation, Sick, etc - que c'est. Il est toujours NULL lorsque job_id est peuplée, et vice-versa)

  • entry_date

  • total_hours

  • ot_exempt (une valeur booléenne qui détermine si l'entrée doit être calculée dans le total des heures supplémentaires)

J'ai besoin de créer un rapport qui peut donner un résumé du temps pour chaque employé, ventilé par état. Je sais que je peux le faire assez facilement en utilisant SUM (total_hours) et GROUP BY job_state, mais la manière dont j'ai besoin de calculer les heures supplémentaires a une logique assez spécifique.

Premièrement, je dois calculer le nombre total d'heures pour chaque employé pour une période donnée. Ensuite, je dois soustraire tout temps qui est marqué comme PTO ou OT Exempt pour obtenir mes heures régulières totales. À partir de là, je peux commencer à compter les heures normales qui dépassent 40 heures par semaine en heures supplémentaires. Ce qui me rend vraiment difficile, c'est que je dois être capable de calculer OT par l'état dans lequel il a été collecté en repérant essentiellement quelle entrée (commandée par entry_date) repousse les heures normales de l'utilisateur à plus de 40 et s'assure ensuite de commencer l'OT pour l'état, le travail particulier est dans (job_state).

Par exemple, si un comité d'entreprise ses 35 premières heures de la semaine dans un emploi en Caroline du Nord et passe alors le 15 suivant sur l'emploi en Caroline du Sud, le rapport devrait montrer quelque chose comme ce qui suit:

Nom de l'employé/emploi État/Reg Heures/OT Heures

Smith, John/NC/35/0

Smith, John/SC/5/10

Et si vous deviez dire que, après avoir travaillé la 15 heures sur le travail SC, il a commencé à travailler sur un autre emploi dans NC il wo Il va falloir commencer à accumuler OT en NC ensuite, puisqu'il aurait déjà plus de 40 heures régulières dans une semaine.Dans le cas où John Smith a terminé la semaine en travaillant 15 heures supplémentaires dans NC son rapport final ressemblerait à ceci:

Nom de l'employé/emploi État/Reg Heures/OT Heures

Smith, John/NC/35/15

Smith, John/SC/5/10

Je suis assez sûr que ce soit quelque chose qui ne peut être accompli en utilisant SQL régulière. Devrais-je utiliser un UDF ou quelque chose comme ça pour accomplir cette tâche? Considérant que je peux facilement obtenir les entrées d'un employé en utilisant une simple requête, suis-je capable de vider l'ensemble de résultats dans l'UDF pour traiter et ensuite produire le résultat souhaité? Sinon, devrais-je simplement inclure et exécuter l'instruction SQL dans le fichier UDF?

Si quelqu'un a des idées sur la meilleure façon d'accomplir cette tâche, je l'apprécierais grandement.

-Mike

Répondre

2

La logique métier appartient à la couche de gestion. Je pense que c'est probablement un peu trop à mettre en SQL (même si c'est possible).

+0

C. Ross, Je vais devoir être d'accord avec vous là-bas. La raison principale pour laquelle j'allais pour la route SQL est parce que je pensais qu'il serait plus simple d'obtenir que le DataSet se lie à mon rapport Telerik. Comme Bryan l'a souligné plus haut (ce qui m'a amené à me donner des claques et à écrire "DUH"), je peux retourner les lignes dans SQL puis effectuer le traitement dans ASP.NET, tout en créant le DataSet requis pour le rapport. Je pense que puisque l'assistant Telerik Reporting recherche une requête sur un objet DB, j'ai mis les blinds SQL et j'ai commencé à charger. – mclark1129

1

Vous pouvez le faire avec plusieurs requêtes à l'intérieur d'une procédure stockée utilisateur (sp). Vous pouvez renvoyer plusieurs ensembles de résultats à votre code ASP.Net pour être consommés par un DataSet avec DataTables dans ASP.Net. Ensuite, vous pouvez l'utiliser pour créer votre rapport.

0

Cela serait probablement mieux géré dans le code. Ce que vous devez regarder dans les bus de service, pas T-SQL fantaisie.

0

N'oubliez pas CLR Stored Procedures. Vous pouvez écrire des DLL .NET qui sont chargées dans votre base de données SQL Server 2005 pour être exécutées en tant que procédures stockées. La logique que vous décrivez est probablement plus facile à implémenter avec un langage .NET (par exemple C#) que TSQL.

Questions connexes