Cart
[Home] [By Thread] [By Date] [Recent Entries]
[oops, forgot to copy replies to the list. Any and all feedback welcome!] Ron, Thanks for the replies... > One thing you should consider then is using XML as a data transport -- > you can think of it as a WAN version of ODBC. There are lots of tools > for transferring data between XML documents and relational databases. In > the case of Access, the simplest tool to use is probably ADO. Yeah, I've started looking into that for the initial transfer of data out of Access, but I probably won't need to put any back in, as I explain below... > The result is that you get portability through XML, rather than storing > your data in XML. For example, you could take your data from Access, > serialize it as XML, and transfer it to SQL Server, Oracle, MySQL, etc. > You then get the benefits of both portability and existing databases. All valid, but overkill for my simple purpose. > I'm not sure about spreadsheets, but Excel might be able to read/write > XML. I also think I've heard that StarOffice on Linux uses XML as its > native format. I've checked into this. StarOffice basically translates a given file into a series of XML files, then zips them into a new (proprietary?) file. Although it will open a standard XML file as plain text, it does not allow you to work with it as a structured document, as far as I've been able to tell. That said, it *is* a pretty nice product. > > To be clear, I have no plans to replace Excel and Access with custom XML > > apps. > > That wasn't clear to me. In your original email, you said "add VBScript > and DHTML to manipulate and query data (to replicate what I'm currently > doing in MS Access". If what you are doing in Access is SQL queries, > storing your data in XML and doing queries with VBScript and DHTML will > guarantee a lot of work (you'll reinvent the wheel writing a query > processor) and poor performance (XML documents are slow to access > without indexes). To clarify further: my current spreadsheet and database are both pretty darn simple, and that's all they need to be for my purposes. All I do is add, modify and delete records, and view tabular lists (not even reports, really). For simple data modification and viewing lists, I *think* XML should work pretty well in my case. I agree: if I were doing "real" queries with SQL, there wouldn't be much point in migrating. As for performance, I'm hoping that my generic plan will take care of that (more below). > It's a great transfer and archive format. I'm not convinced it's a good > format for working copies of data that fits well into a database or > spreadsheet. Since I use both my spreadsheet and database as nothing more than formatted displays for reference, I think XML should do the job well. > > The music collection started as a spreadsheet, which I planned to migrate [...] > Fair enough. I just thought I'd throw in my two cents. One of the most > common XML/database questions I see is people wanting to throw away > their databases and use XML instead. In the overwhelming majority of > cases, this is a bad idea, but there are always exceptions. I understand. I think it will work in my case since I basically just need some customized displays of (mostly) static data. Here's my current pseudo-flowchart plan: artists.xml contains artist names and notes, with tagged references to individual [artistname].xml files [artistname].xml contains <releases> by the artist, with associated <track> lists and <notes> for each release. The VBS/DHTML would have a main display that lists artist names from artists.xml. On choosing an artist, individual [artistname].xml files would be loaded. I would probably show only certain information by default, and further information at the click of "More detail" buttons. I would also have "Edit" buttons to modify/add/delete artists, releases, or any other information. The only real querying I plan to do is list: all <artists> all <releases> by an <artist> all <releases> by all <artists> (if not too slow) all <tracks> on a <release> all <releases> purchased in last month or year all <releases> total cost/value All of that should be pretty straightforward with VBS/DHTML. I'm hoping that separating each artistname.xml file will help with speed of loading/display. Any more thoughts? Thanks, Lee
|
