[
Lists Home |
Date Index |
Thread Index
]
[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
|
