Enregistrer une table dans une autre table sql server automatiquement

Version imprimable

28/05/2017, 17h41
Massigne

Enregistrer une table dans une autre table sql server automatiquement
Salut à tous jai créé une table comptage et une table compteur, les deux tables sont identiques
je voudrais voudrais qu'a partir d'une date bien définit enregistrer les données de la table comptage dans la table compteur et ensuite vider la table comptage pour nouvelle remplissage j'ai écrit la requette suivante
Code:

1 2 INSERT INTO [compteur] select * from [dbo].[comptages] DELETE FROM [dbo].[comptages]
je voudrais savoir s'il est possible d'écrire une fonction qui permet d'enregistrer les données dans la deuxième table et vider la première table si oui comment procéder? merci pour votre aide
28/05/2017, 20h09
jcdentons

Sujet lié : https://www.developpez.net/forums/f13/dotnet/
29/05/2017, 12h20
SQLpro

Citation:

Envoyé par Massigne

Salut à tous jai créé une table comptage et une table compteur, les deux tables sont identiques
je voudrais voudrais qu'a partir d'une date bien définit enregistrer les données de la table comptage dans la table compteur et ensuite vider la table comptage pour nouvelle remplissage

Le plus intelligent serait d'utiliser le partitionnement. C'est nettement plus adapté et plus performant (pas de blocage)...

A +
29/05/2017, 16h39
StringBuilder

Citation:

Envoyé par jcdentons

Sujet lié : https://www.developpez.net/forums/f13/dotnet/

Le lien ne marche pas : on arrive sur la page d'accueil du forum

Citation:

Envoyé par SQLpro

Le plus intelligent serait d'utiliser le partitionnement. C'est nettement plus adapté et plus performant (pas de blocage)...

A +

Et encore, quel est le véritable besoin ?
Comment est alimentée cette table "temporaire" ? Pourquoi faut-il que ces données soit totalement écartées des autres données ? (droits, contraintes ?)

J'avoue ne pas comprendre le besoin qui se cache derrière la question.

Edit : Ok, j'ai trouvé le lien en doublon : https://www.developpez.net/forums/d1...tomatiquement/
29/05/2017, 18h13
Massigne

2 pièce(s) jointe(s)

Merci StringBuilder de prendre du temps à consacré à mon problème. voila la table comptage que j'appelle encore Relevé_Compteur_EnergiePièce jointe 280507
Me permet d'enregistré les indexes du compteur d'énergie électrique au quotidien je voudrais donc que le 26 de chaque mois les données soit enregistré et que la table soit vider pour que je puisse enregistrer les données du nouveau mois c'est la raison pour la quelle j'ai créé deux table identique
Pièce jointe 280514
et c'est donc la requette sql que je ne métrise pas car l'application sera installer dans des ordinateur ne disposant pas sql server
29/05/2017, 18h15
Massigne

Bonsoir SQL pro lorsque vous parler du partitionnement je ne comprend pas

La solution est trouvé par jcdentons
juste avec une fonction

Code:

1
2
3
4
5
IF (DAY(GETDATE()) = 29)
BEGIN
 INSERT INTO [dbo].[Relevé_Compteur_EnergieA]  select * from [dbo].[Relevé_Compteur_Energie]
DELETE  FROM [dbo].[Relevé_Compteur_Energie]
END

Citation:
Envoyé par Massigne
La solution est trouvé par jcdentons
juste avec une fonction
Code:

1 2 3 4 5 IF (DAY(GETDATE()) = 29) BEGIN INSERT INTO [dbo].[Relevé_Compteur_EnergieA] select * from [dbo].[Relevé_Compteur_Energie] DELETE FROM [dbo].[Relevé_Compteur_Energie] END
Bonsoir Massigne,

Sans plus d'information, je pense que vous partez sur une mauvaise modélisation.

Le fait de séparer physiquement les données en deux tables ne doit pas être motivé par la supposition de mauvaises performances à l'avenir : il y a peu de chances que cela arrive avec une base bien modélisée, même sans tuning particulier.
Un peu de lecture ici pour vous convaincre : http://wiki.c2.com/?PrematureOptimization

Il reste donc en suspens les questions que je vous ai posé :
- Les données "du mois en cours" ont-elles des contraintes différentes de celles historisées ? (par exemple, possibilité d'avoir des plusieurs lignes à une même date, qui seront alors cumulées lors de la recopie dans une nouvelle table)
- Les données "du mois en cours" sont-elles importées d'une manière où d'une autre qui nécessite que la table soit vide avant l'import ?

Si ce n'est pas le cas, alors à mon avis vous faites totalement fausse route.

Créer une unique table : celle de destination.

Puis faites deux vues :

v_comptages :
Code:

1 2 3 4 5 6 create view v_comptages (date_heure, t1_12kw, t1export, ...) as select date_heure, t1_12kw, t1export, ... from compteur where date_heure >= cast(case when day(getdate()) >= 26 then dateadd(day, 26 - day(getdate()), getdate()) else dateadd(month, -1, dateadd(day, 26 - day(getdate()), getdate())) end as date)
v_compteur :
Code:

1 2 3 4 5 6 create view v_comptages (date_heure, t1_12kw, t1export, ...) as select date_heure, t1_12kw, t1export, ... from compteur where date_heure < cast(case when day(getdate()) >= 26 then dateadd(day, 26 - day(getdate()), getdate()) else dateadd(month, -1, dateadd(day, 26 - day(getdate()), getdate())) end as date)
La syntaxe est un peu barbare, mais tout à fait performante.
Un simple index sur date_heure permettra de conserver des performances tout à fait identiques à l'utilisation de deux tables distinctes.

Quant au partitionnement proposé par SQL Pro, il est disponible sur la version Entreprise de SQL Server (donc je pense hors sujet ici) et cela permet de répartir le contenu d'une table dans plusieurs fichiers selon un critère (ici, la date pivot du 26 dernier) : ainsi, en conservant une seule table d'un point de vue logique, on a bien deux tables distinctes d'un point de vue physique.

C'est notamment utile quand la table du "mois en cours" est intensément mise à jour (par exemple, des milliers de lignes par minute) alors que l'autre est un historique qui n'est utilisé que pour des statistiques, de temps en temps : la partie "vivante" va alors sur une baie de disques haute performances, tandis que le reste de la table (le gros des données) par sur une baie low cost.

29/05/2017, 22h53
Massigne

Merci StringBuilder
En fait j'ai créé un DataGridview en VB.net et je saisi les données directement dans le DataGriview or en 1 mois les données saisis serons assez volumineuse j'ai donc penser vider la table chaque 26 du mois
en enregistrant les données qui existai déjà c'est donc que j'ai eu l'idée de créé deux tables identiques.
l'une pour saisir les données et les conserver jusqu'au 26 et l'autre pour récupérer les données.
et les données sont saisis une seule fois par jour et sur une seule ligne par jour.
30/05/2017, 09h06
StringBuilder

Bonjour Massigne,

On est donc typiquement dans le cas que je pensais : vous faite du "premature optimization", c'est à dire que vous complexifiez votre code (et architecture) en prévision d'hypothétiques lenteurs qui ne sont ni certaines, ni impossible à résoudre de façon plus propre et transparente.

Vous avez donc deux besoins :
- La possibilité de faire une sélection des données "du mois en cours", et de mettre à jour ces données (CRUD)
- La possibilité de faire une sélection des données "des mois passés", et d'en faire des statistiques (par exemple)

Dans un premier temps, vous pouvez donc partir sur les deux vues que je vous ai proposé :
- select * from v_comptages permettra d'alimenter le datagrid. Vous pourrez sans problème faire du CRUD dessus, puisque la vue ne fait pas de jointure ni de regroupement : elle va donc permettre un accès direct aux données de façon transparente.
- select * from v_compteur permettra d'interroger les mois passés en toute transparence.

Un index sur compteur(date_heure) vous sera très certainement utile.
Si vous disposez d'une version Entreprise de SQL Server, vous pourrez partitionner en plus la table, de façon à encore optimiser les ressources, de façon totalement transparente pour votre code et le modèle des données.
30/05/2017, 12h07
SQLpro

Citation:

Envoyé par Massigne

Bonsoir SQL pro lorsque vous parler du partitionnement je ne comprend pas

Le partitionnement consiste à séparer le stockage des lignes de votre table en autant de partitions que l'on souhaite d'un point de vue physique, mais laisse la table logique inchangée.
Cela possède le double avantage de n'avoir qu'une seule table et les performances équivalentes à deux tables séparées.

Pour mettre en œuvre la partitionnement il existe un assistant.

A +
31/05/2017, 04h40
Massigne

Merci SQLpro
31/05/2017, 05h18
Massigne

Bonjour StringBuilder et grand merci pour votre temps que vous consacré à mon problème. A moins que je ne comprend totalement vos explication ou moi même je ne me fait pas très bien comprendre. j'ai déjà retenu une chose avec votre méthode je pourrai facilement interroger la table en fonction de la date.
Je vais essayer d'apporter plus de précision à mon problème:
Voila en électricité industriel il y a se qu'on appel le facteur de puissance; lorsque sur un mois de consommation d'énergie électrique votre facteur de puissance est inférieur à une certaine valeur (<0,8) dans mon pays vous payer les pénalités dû au mauvais facteur de puissance. Mon objectif est de créé une application qui permet à un employer quelconque d'une usine de relever l'index du compteur d'énergie quotidiennement et de déterminer le facteur de puissance par jour afin de procéder au correction de ce facteur de puissance si nécessaire. C'est dans cette optique que j'ai créé la table [dbo].[Relevé_Compteur_Energie] ou les enregistrements des index sont fait une fois par jour et la date est définit comme clé primaire. Je voudrais donc qu'a la fin du mois la DataGridview que l'utilisateur utilise pour l'enregistrement des données se vide complètement à fin qu'on puisse saisir les données d'un nouveau mois sans plus voir apparaître dans la dataGridview les données des mois passés mais sans toute fois supprimer les données des mois passés. c'est donc pour cette raison que j'ai pensé créé deux tables identiques.
Si j'apporte plus de précision ici c'est tous simplement que je ne parvient pas à bien comprendre votre solution ou c'est moi qui ne me fait pas bien comprendre mais j espère qu'a travers ces explications vous pourrez mieux m'aider. Encore merci
31/05/2017, 09h12
StringBuilder

Bonjour,

Donc on est exactement dans le cas où deux tables n'apportent rien : 1 ligne par jour, ça va représenter, après 10 ans, seulement 3600 lignes, ce qui est ridicule (à la limite, même un fichier XML permettrait de conserver de bonnes performances avec un tel volume).

Donc la seule raison d'avoir deux ensembles distincts de données, c'est que d'un côté, on veut historiser les lignes (pour par exemple étudier l'évolution sur le long terme, comparer les relevés avec les factures et pénalités reçues, etc.) et d'un autre côté, un ensemble de donnes qui ne correspondent qu'aux données du mois en cours.

Si le pivot du "26 du mois" est bel et bien fixe et ne devra jamais évoluer d'un client à l'autre ou d'une année sur l'autre, alors la solution des vues est, à mon sens, parfaite.
Si ce pivot peut changer, une simple requête avec un filtre sur la date me semble plus pratique.

Dans tous les cas, pour moi, il faut une et une seule table.

Et une vue pour ne récupérer que les lignes du mois en cours, qui servira à alimenter le datagridview.
Ainsi, sans aucune action dans la base de données, lorsqu'on change de date, le jeu de données affiché s'adapte.

Ensuite, dans SQL Server, une vue peut être mise à jour : on peut faire ce qu'on appelle du CRUD (Create / Retrieve / Update / Delete) soit toutes les instructions SQL INSERT, SELECT, UPDATE et DELETE.
Lorsque la vue effectue des calculs, jointures ou regroupements, on a parfois besoin d'y accoler des triggers pour lui expliquer quoi faire des données mises à jour. Ici, avec les exemples de vue que j'ai donné, aucun besoin de trigger.

Donc vous faire une et une seule table.
S'il n'y a qu'un relevé par jour, optez pour le type "date" et non "datetime" pour la date : ce sera plus performant, et avec une clé primaire, ça garantira qu'il n'y a qu'un seul relevé par jour.

Ensuite, vous créez la vue que j'ai donné en exemple pour obtenir les relevés du mois en cours.

Et c'est cette vue que vous interrogez et mettez à jour (comme si c'était une table depuis votre programme).

L'avantage, c'est qu'ensuite les requête pour comparer par exemple la semaine en cours avec les 5 semaines passées sera largement simplifiée puisque toutes les données seront dans la même table.

Voici un exemple complet (côté SQL Server) de ce que ça donne.

Je suis parti du principe français des heures pleines et heures creuses, avec un coefficient calculé par le ratio des heures pleines par rapport aux heures creuses.

J'imagine que je suis très loin de votre règle de calcul, mais ça permet de voir un peu ce qu'il est possible de faire.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
 
-- Histoire de pas mettre le boxon dans votre base, on crée un nouveau schema
create schema massigne;
go
 
-- La table de releve : on note la présence d'une colonne calculée pour le coefficient : plus propre que de stocker la donnée calculée
create table massigne.releve
(
	jour date primary key,
	pleine int not null,
	creuse int not null,
	check (creuse > 0),
	coefficient as cast(pleine as float) / cast(creuse as float)
);
go
 
-- La vue de travail : c'est cette vue qui doit être utilise dans le programme VB.NET
create view massigne.v_comptages (jour, pleine, creuse, coefficient)
as
select jour, pleine, creuse, coefficient
from massigne.releve
where jour >= cast(case when day(getdate()) >= 26 then dateadd(day, 26 - day(getdate()), getdate()) else dateadd(month, -1, dateadd(day, 26 - day(getdate()), getdate())) end as date)
go
 
-- On insère quelques données pour illustrer le fonctionnement
insert into massigne.releve (jour, pleine, creuse) values
('2017-05-01', 1, 1),
('2017-05-02', 10, 20),
('2017-05-03', 30, 30),
('2017-05-04', 50, 60),
('2017-05-05', 60, 80),
('2017-05-06', 75, 100),
('2017-05-07', 85, 130),
('2017-05-08', 100, 135),
('2017-05-09', 115, 140),
('2017-05-10', 130, 160),
('2017-05-11', 140, 170),
('2017-05-12', 150, 210),
('2017-05-13', 160, 220),
('2017-05-14', 180, 225),
('2017-05-15', 210, 240),
('2017-05-16', 215, 260),
('2017-05-17', 230, 290),
('2017-05-18', 250, 300),
('2017-05-19', 245, 305),
('2017-05-20', 255, 305),
('2017-05-21', 280, 315),
('2017-05-22', 305, 340),
('2017-05-23', 310, 360),
('2017-05-24', 320, 380),
('2017-05-25', 330, 430),
('2017-05-26', 350, 440),
('2017-05-27', 375, 450),
('2017-05-28', 390, 460),
('2017-05-29', 400, 475),
('2017-05-30', 420, 480),
('2017-05-31', 425, 505);
 
-- On vérifie que toutes les données sont bien là
select * from massigne.releve;
 
-- La vue n'affiche les lignes qu'à partir du 26 mai 2017
select * from massigne.v_comptages;
 
-- On insère une ligne directement dans la vue (et ça marche !)
insert into massigne.v_comptages (jour, pleine, creuse) values ('2017-06-01', 440, 530);
 
-- On vérifie que la vue affiche bien la nouvelle ligne (elle est aussi, bien évidement, présente dans la table massigne.releve)
select * from massigne.v_comptages;

Bien plus simple à utiliser qu'une recopie d'une table.
Et ce sera en plus plus performant, car la recopie d'un lot de données d'une table à une autre est toujours une opération coûteuse.

31/05/2017, 13h44
Massigne

Bonjour StringBuilder et vraiment merci pour l'instant je suis au boulot et je vais tester dans l'après midi