January 18, 2011 at 10:25 pm
To export the entire data base into an XML file , and updating that xml file dynamically. Means we can communicate directly with this xml file only in place of communicating with Data Base directly
January 18, 2011 at 11:07 pm
I hope it's a really, really, really tiny database.
Why do you want to do something like this?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 20, 2011 at 9:35 am
No, it really a large data base, that's the reason in place of communicating directly with database, to communicate with that xml file?
January 20, 2011 at 9:49 am
Let me see if I have this straight, you want to export a really large database to XML, producing a really, really large XML file, then you want to make changes (single user I hope) to that really, really large XML file, then you'll want to sync all of that data into the database?
Why? What problem are you trying to solve here?
SQL is designed and optimised for data access from anything from tiny really huge databases. That's what it's good for. XML is a verbose and not-particularly-efficient way of storing data, designed for self-documenting data exchange between disparate systems. Exporting portions of the DB to serve as client-side caches I can understand. Exporting the entire DB?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 20, 2011 at 10:08 am
bvkrishnareddy.bandi (1/20/2011)
No, it really a large data base, that's the reason in place of communicating directly with database, to communicate with that xml file?
Just consider the following scenario:
Let's assume you have a database with 100 tables, some of those holding up to a few million rows, some of them just a few hundred. If you update a value in a single row in a table holding a few hundred rows, SQL Server will access either just the single page holding the row in question or at most it will access the entire table.
When dealing with an XML file the system would have to load the file as it is and work on a much larger data volume than just the single page or table (not even considering the additional tag overhead).
Aside of the performance issue is there is data consistency. How would you implement a foreign key reference concept into the "XML DB"?
If there are performance issues, there are much more efficient (and much more promising) ways to tackle the issue.
January 20, 2011 at 12:32 pm
just being advocate of the devil :sick:
Pull all your wanted tables to a .net dataset and just export it into an xml file.
Piece of cake.
The big question remains: Why do you want to do that ???
An actual database engine provides way more reliability, security, stability, ...
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data and code to get the best help
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Who am I ? Sometimes this is me but most of the time this is me
Viewing 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply