Discussion :

[CHoule]

Bonjour,

J'aimerais connaître qu'elle sont les avantages et inconvénient d'utiliser un API java pour faire de la synchronisation de BD SQL Server.

Qu'elle sont les options les plus avantageuses

Utiliser le change tracking de sql server
Utiliser hibernate

Merci

[julien94320]

Bonjour,


Je vais répondre rapidement à la question :

L'utilisation d'ORM tel que hibernate peut ralentir significativement le SGBD en utilisant les requetes non optimisés. Il est préférable de maitriser la couche de données et de privilégier des vues, des procédures stockées et des fonctions dans un model bien conçu mais la nous somme dans un monde parfait

En générale utiliser un ORM va vous ralentir car vous allez rajouter une couche supplémentaire non maitrisé.

Vous pouvez utiliser les options de change traking intégré dans SQL Server si vous le souhaitez, elles sont conçu pour ça et elles ont beaucoup plus de chance d'etre plus rapide que l'utilisation d'hibernate.

Maintenant, il n'y a pas de réponse miracle, tout dépendant de vos données, de vos besoins, de votre utilisations, de la modélisation, ... Bref il n'y a pas de vrai réponse, et souvent la vrai réponse nous la trouvons après un audit et après avoir fait des tests.

La bonne réponse etant qu'est ce que je veux ? Et comment l'obtenir ? Quels sont les moyens ? Quelle est ma configuration actuel ? Quel version de SQL Server utilisez vous ?

Savez vous que sur SQL Server 2016 il existe les temporal table qui sont conçu pour de l'audit de base et qui sont très performantes ?

On ne connait pas tout le contexte et dans ce cadre nous ne pourons vous aiguiller correctement.

A+

Julien

[SQLpro]

Bonjour,

J'aimerais connaître qu'elle sont les avantages et inconvénient d'utiliser un API java pour faire de la synchronisation de BD SQL Server.

Qu'elle sont les options les plus avantageuses

Utiliser le change tracking de sql server
Utiliser hibernate

Merci

Quel est l'intérêt d'avoir une voiture et de la faire circuler sur un camion ?
Rajouter des couche diminue les performances, rend les diagnostics complexes en cas de problème et limite les fonctionnalité. Utilisez les outils interne dédiés à ce genre de choses qui le font très bien de serveur SQL à serveur SQL :
0) AlwaysOn ou Mirroring
1) la réplication de données qui existe en 4 modes différents (transactionelle, snapshot, fusion et peer to peer)
2) Change Tracking ou Change Data Capture
3) service broker
4) serveurs liés et triggers
5) SSIS
...

Tout dépend de votre problématique fonctionnelle.... À quoi va vous servir cette synchronisation ?

A +

A +

[Invité]

Quel est l'intérêt d'avoir une voiture et de la faire circuler sur un camion ?

SQLPro, expert en analogie imagée !

[CHoule]

Tout dépend de votre problématique fonctionnelle.... À quoi va vous servir cette synchronisation ?

Merci pour vos réponses rapide,

Je vous soumets un peu plus de détail.

Nous avons une BD centralisée contenant l'information de configuration partageable. L'information étant centralisé le manager doit sélectionné dans qu'elle autre BD les différentes configuration seront synchroniser. Nous conservons l'id de la BD centralisé en référence dans les BD synchronisées.

IL y a possibilité d'installer les BD sur différent serveur, c'est la raison pour laquelle nous passons par un API Java.

1 API pour la BD centralisé
1 API pour chaque autre BD (2 a +++)

Donc les options explorés sont

C'est l'API centralisé qui gère la "schedule" de synchro et qui valide a qu'elles autre BD l'information doit être envoyé.

1- API centralisé qui fait appel aux Store Proc "Get" sur la BD centralisé (SP utilisant le Change tracking de sql)
API local qui fait appel aux Store Proc de "Sync" sur chaque BD local, c'est au niveau de chaque SP que la gestion de l'id de référence se fait.

2- Trigger Insert,update,delete sauvegarde l'information modifier dans une colonne de type XML ce trigger remplace la Store proc "Get" .
Exemple de trigger:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
CREATE TRIGGER [dbo].[C_acCreditCard] ON [dbo].[acCreditCard] FOR UPDATE, INSERT, DELETE NOT FOR REPLICATION AS
BEGIN
	SET NOCOUNT ON;
	IF (SELECT PROPERTYGUID FROM prProperty) = 9 --ONLY FOR HEAD OFFICE
	BEGIN
		DECLARE @XMLValues NVARCHAR(MAX) = ''
		IF EXISTS(SELECT * FROM inserted) --Insert ou update
		BEGIN
			INSERT INTO SystemCodeChangeTracking (ChangeDateTime, EntityName, XMLValues)
			SELECT GETDATE(), 'acCreditCard', CONVERT(NVARCHAR(max), (SELECT * FROM Inserted FOR XML PATH('acCreditCard'),type,elements absent)) 
		END
		ELSE IF EXISTS (SELECT * FROM deleted)			
		BEGIN
  		 INSERT INTO SystemCodeChangeTracking (ChangeDateTime, EntityName, XMLValues)
		 SELECT GETDATE(), 'acCreditCard', CONVERT(NVARCHAR(max), (SELECT * FROM Deleted FOR XML PATH('acCreditCard'),type,elements absent))
		END
	END
END

3- Retrait des Stored proc. Gestion complète par l'API Java, sans stored proc de "Sync".

Nous utilisons la version SQL 2014 c'est la raison pour laquelle nous XML, JSON étant disponible seulement en SQL 2016


Donc qu'elle sont les avantages ou inconvénients de préféré l'option 3 aux 2 autre options?

Je connais très peu Java, mais j'ai toujours penser qu'il n'y avait rien de mieux que SQL Server pour gérer des BD SQL Server

Merci d'avance
Chantale

[SQLpro]

Le mieux serait d'utiliser Service Broker dans ce cas. Il serait parfaitement adapté car sérialisé, transactionné, fiabilisé et sécurisé, et perforant, java n'offrant pas ces possibilités de manière naturelle.

A +