Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 2 of 2
03-23-2009, 06:56 PM #1
- Join Date
- Nov 2008
- The Great Pacific NW, USA
- Thanked 6 Times in 6 Posts
Should I use a table or XML for not-necessarily tabular data?
First, let me lay the ground work.
I am going to have a "Part Work Screen" (php) pulling info from our database (stock levels, quote/sales history, etc).
This is all tabular data, so I know that a DB is the best place for that info, but
I will also be pulling series level data, and this isn't inherently tabular.
(please keep in mind that I'm a bit of a noob.)
<series> <pdf link/> <pdf link/> <photo link/> <photo link/> <photo link/> </series>
It seems to me that using a table would kinda be like "wasting space".
Am I correct in thinking that XML would be best suited for this?
Note: For starters, there are probably about 15k different series representing about 65k part numbers. This will continue to grow.
I can, however, parcel out the XML and have a separate data-island for each PN Category (ie: machines, people, animals) if size tends to be a hurdle for XML.
I'm looking for some advice and/or suggestions from the seasoned pro's (or anyone with something to add).
NOTE: Realizing I may get a slightly biased opinion or two, I will also post this in the XML group to see what kind of biased opinions I can milk out of them , then reconcile everything together.
Last edited by mOrloff; 03-23-2009 at 07:17 PM. Reason: notice of intent to dual post.
03-23-2009, 08:33 PM #2
But how will you MAINTAIN the XML??
If it's truly static (never changing) data, then sure, go the XML route. Or, heck, just make an HTML file that you include.
But if it's updated even as often as once a month, I would think you would want a DB for the inherent editing capabilities. Now, what you might do is *both*. After editing the DB, you run private set of code (web or standalone) to generate the XML file. But if you edit the DB often, then I'd just go straight DB and/or DB-to-XML-on-the-fly.