• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

I need to somehow pull values out of an SQL database and place them into xml file

D

dalearyous

Senior member
Ill try to explain this as clear as i can, i am taking in values from a form and storing them into a database. problem i am having (because im new to this stuff) is every time someone is added to the database i need 2 of the values to be placed into an xml file which is like the info file of a map. any ideas specifically or conceptually?

or, forget even using the database for this...
in my php file i have the values assigned to variables...is it possible to write those variables into the xml file?
 
Originally posted by: dalearyous
...ah didn't know i could do that in an xml file
Click to expand...

I'm pretty sure you can get the values from the SQL server and write them to a xml file via php script. I don't know php though. I'd recommend doing some searches on groups.google.com. Lots of good info on there.
 
You can do that easily. Use the fopen, fread and fwrite functions in php. I'm assuming you just want to append data to the existing file so open and read the xml file, trim the closing tags (trim function) if necessary, append the new data and replace the closing tags (if necessary).

Or, if you have all info (both existing data and new data) for the xml file in the database, just rewrite the entire file using fopen and fwrite.

I do this for one of my projects using the second method, rewriting the xml file. If you are not storing all data in the DB then the first method would be appropriate.
 
Depending on the database that you're using you might be able to use a trigger to recreate the XML file everytime an update happens.
 
Originally posted by: Nothinman
Depending on the database that you're using you might be able to use a trigger to recreate the XML file everytime an update happens.
Click to expand...

I was going to mention that exact same thing...
 
Originally posted by: Fallen Kell
Originally posted by: Nothinman
Depending on the database that you're using you might be able to use a trigger to recreate the XML file everytime an update happens.
Click to expand...

I was going to mention that exact same thing...
Click to expand...

thats pretty much exactly what i want...how do i make that happen?
 
Originally posted by: dalearyous
Originally posted by: Fallen Kell
Originally posted by: Nothinman
Depending on the database that you're using you might be able to use a trigger to recreate the XML file everytime an update happens.
Click to expand...

I was going to mention that exact same thing...
Click to expand...

thats pretty much exactly what i want...how do i make that happen?
Click to expand...

Why not answer this question first?
 
Why bother with a trigger? Why not just have the same script that writes the data to the database create the XML file?
 
Why bother with a trigger? Why not just have the same script that writes the data to the database create the XML file?
Click to expand...

That could work but it's more reliable to let the DB do it since you don't have to worry about other, old, etc scripts touching the database and not recreating the file. Of course the need for the XML file is pretty sketchy anyway...
 
Any enterprise DB will have ZERO triggers. Emphasis on the ZERO. Anything that can be done via a trigger can easily be done at the application level most of the time. Hence, n-tiered architecture.
 
Originally posted by: Nothinman
Why bother with a trigger? Why not just have the same script that writes the data to the database create the XML file?
Click to expand...

That could work but it's more reliable to let the DB do it since you don't have to worry about other, old, etc scripts touching the database and not recreating the file. Of course the need for the XML file is pretty sketchy anyway...
Click to expand...

Respectfully, I completely and totally disagree.

From the description he gave, he has a map integrated into his application which takes coordinates in the form of an xml file. He has a script written to accept new coordinates and a database to house them for the other parts of his application. There is no reason the script that accepts user input and adds it to the database cannot also generate the XML file. It's more portable, likely faster, and much simpler. Why over-complicate things?

Also, what about the case where the database and the application are not on the same server? Not gonna work.

Dhaval's advice is sound. Let application-level tasks be completed by the application.
 
Originally posted by: Dhaval00
Any enterprise DB will have ZERO triggers. Emphasis on the ZERO. Anything that can be done via a trigger can easily be done at the application level most of the time. Hence, n-tiered architecture.
Click to expand...

What? I have a half a million dollar piece of software sitting in my datacenter that runs on 4 very large sun servers and a vast amount of disk space that would like to punch you in the mouth for that comment.

Abstracting database logic from programing is usually a good thing. For example, I need to get X data, so does my partner programmer. We could use a trigger/view/whatever and be consistent, or I could write my sql and he could write his. If his is more efficient I can go back though my code find my stuff and replace it, push that out to my clients in a patch, etc. If we used a view or a trigger we can just rewrite the that. As long as the output is the same we have saved tons of time.

As for having the application that adds to the db make the xml file. What if more then one application writes to the db?

personally, assuming this is some kind of web application. I'd make the xml file really be just a php/python/whatever script that generates it every time it is called.
 
Let's not get into the bragging rights... for security reasons I cannot disclose about the systems our teams work on (think along the lines of the state law enforcement agencies and federal agencies), but believe me when I say that your half-a-million piece of software is chump-change compared to the ginormous systems we deal with. We've consulted with various firms (the likes of Deloitte and Accenture), have great in-house DB developers/admins, and all increasingly seem to agree on one thing: what can be done via triggers can also be done via n-tiered architecture (think of Web Services, Daemons, Microsoft-specific things like Notification and Integration Services, Data warehousing, etc). Couple of big reasons being that your transactional system can't be bogged down the cyclical nature of triggers (cascades) and ambient transactions. Add to that the additional headache of maintainability, debugging, etc.

Here are a few (Oracle and SQL Server) articles from the very people who help built those two DB engines:

http://blog.sqlauthority.com/2...-problems-of-triggers/
http://rwijk.blogspot.com/2007...triggers-are-evil.html
http://www.oracle.com/technolo.../08-sep/o58asktom.html

Again, no one's going to stop you from using triggers, but sooner or later you'll realize that they seriously hinder your scalability... unless your DB is growing at a very slow rate and you won't be there to maintain it when the problems props up.


Edit: Just to put it out there, when I started working with DB's, I was responsible for deploying triggers, too. Now that I reminisce about the design, I'd like to go back in time and get rid of those triggers - simply because they have created many problems. And it's not just me, I am maintaining others' trigger-problems, too.
 
I'm just going to to trust the company we are buying it from. I mean they make the software that basically is ran at every single major university in the nation and growing rapidly in the world. If it's good enough for them, it's good enough for the stuff we write around their product (and it keeps us consistent with their product). Truthfully, on top of that, I much rather tell my database team what data I need then try to figure out what the best way is myself (as there is no possible way for me to keep up to date with the structure of the database, hell my module that I'm responsible for has more tables then I could even dream of remembering). They are the experts. But what would be worse would be having to touch every single report I write and change sql in it. Sure it is easy if I have a nice java class for all these calls, but it's hard to do that with all the things I'm asked to write.

I understand the argument. Sometimes hard hitting logic is put on our app server because we don't want the load there. But for a lot of things I just don't see the business reason. It creates a management nightmare for us, moves our load from a small group of devs to a large group, and it has a potential to bite us in the ass when devs outside of our control change the main business application we use.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top