|
Re: Perl/XML/MySQL
by mirod (Canon) on Nov 12, 2000 at 04:30 UTC
|
Well the first thing you can do is export your table
in a simple XML format that maps the tables so clients
can use it for whatever use, maybe feeding another DB, or
filtering out some information, or adding some more,
or presenting differently.
_you_ don't have to store the information in XML, but
making it available in such a way makes it much more
easy for others to re-use it. A time element is
much easier to process than the second column of a table.
Especially if (when) at some point in the future you change
the structure of your table and you add an extra field in
between the first 2. HTML processors will be all messed up
while, if written properly XML clients will still work fine.
On the other hand of course you might not want clients to be able to
re-create your data base and you might want to avoid exporting XML.
The nice thing about XML on the client side is that it is a
slightly self-documented format, standard, stable, and that
can be processed using a lot of different tools, form XSLT
processors to Java libraries and to Perl modules.
And if you just _have_ to export XML because your boss
told you so, then have a look at DBIx::XML_RDB which will
do it painlessly and efficiently.
| [reply] |
Re: Perl/XML/MySQL
by Fastolfe (Vicar) on Nov 12, 2000 at 06:51 UTC
|
XML isn't such a great way to store data. That's what databases are for. Instead, think of it as a way to move data, or distribute it, in such a way that it can be picked up and used by a variety of applications without costly translations between different data formats. XML is a way of representing data in a very generic fashion, so that it can be viewed or manipulated by any other application supporting XML. If this is of little use to you with your project, you probably don't want to use XML. | [reply] |
RE: Perl/XML/MySQL
by BastardOperator (Monk) on Nov 12, 2000 at 08:47 UTC
|
I'm not sure, but you may just be trying to force XML into a situation where it truly isn't needed. XML is not an end all solution to all of your programming problems. XML is an excellent solution to a lot of problems though. User configuration, multi-language environments which need to share data, and business to business data exchanges are just a few.
I will, however, add one (sort of) new technology that may (or may not) help here, XHTML. XHTML is simply HTML which is XML compliant. For instance a <BR> tag would look like <br/>, etc. In this way you could use LWP::Simple and XML::Parser to get the html page and easily parse it. That way users can use the data for other applications, simply by getting the page and grabbing the relevant info.
I thought about doing a web-site football pool (still might, haven't gotten around to it) for work, looked at http://football.espn.go.com/nfl/scoreboard and figured that every week, I could just grab the info from that site as to who is playing, who's at home, etc, but the data (html) would be a little difficult to extract. If they used XHTML it'd be a breeze. | [reply]
[d/l]
[select] |
Re: Perl/XML/MySQL
by AgentM (Curate) on Nov 12, 2000 at 03:40 UTC
|
Many SQL engines (and perl modules) are more than happy to export the tables to XML. Why? Because you can then move them somewhere else (on a disk, perhaps) to another machine, where it may be accepted happily by another dbengine (not necessarily even an SQL or the same dbengine) and still retain full use of the data (with some minor tweaking). But if, you're not doing anything like this than using XML for anything db-related is superfluous. In general speed(dbegine)>speed(DB_File)>speed(XML file) since XML is a plain text format. It will be easier and faster to extract than interpreting an XML file. But XML has other uses....but since you don't ask....
I'll answer anyway. XML was once considered a replacement for HTML- but that didn't pan out. XML makes a great human-readable config file format as well as a nice cross-platform format in general, which makes it useful in many situations...
AgentM Systems nor Nasca Enterprises nor
Bone::Easy nor Macperl is responsible for the
comments made by
AgentM. Remember, you can build any logical system with NOR.
| [reply] |
|
|
XML was once considered a replacement for HTML- but that didn't pan out.
Both halves of that statement are provably wrong.
XML is the replacement for SGML.
And XHTML (the XML-ized version of the SGML-based HTML standard) is the
new standard for Web browsers, says the W3, of whom Netscape (now AOL)
and Microsoft are big members and players.
Today's tip: People will trust the rest of your answers better when you stop making stuff up when you post.
-- Randal L. Schwartz, Perl hacker
| [reply] |
|
|
Well, actually both statements are probably (and may be
even provably ;--) true.
XML was developed by people from the SGML world as a way
to capitalize on HTML's success and to re-marked SGML in
a more "you-can-do-it-too" way.
So for SGML people (of which I didn't know you were one merlyn!)
XML is the replacement for SGML, but it was really proposed
and pushed as a replacement for HTML. And it is still widely perceived as
"the future of HTML".
As I saw it once XML is "HTML on steroids", and conversely
it is "SGML on Prozac".
The bottom line is that XML is whatever you want it to be,
and I don't think beating up on people who see it from the HTML
angle is a good way to promote it.
| [reply] |
|
|
Re: Perl/XML/MySQL
by clemburg (Curate) on Nov 12, 2000 at 23:56 UTC
|
Ever invented your own syntax for an
intermediate data format?
Ever see it failing? Well, XML will spare you that.
It is widely accepted and supported, and much more capable than
any of its simple-minded cousins, like CSV or the
proprietary intermediate data formats of some of the
big database vendors. And it spares you
to learn SGML. Well, unless you want to learn something
about the ultimate data language out there ;-).
Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com
| [reply] |
Re: Perl/XML/MySQL
by elwarren (Priest) on Nov 12, 2000 at 05:18 UTC
|
XML can seem pretty worthless to a perl hacker. I've been
thinking about this and I think the reason is DBI. IMHO, the
DBI/DBD interface in perl is one of the greatest inventions
since sliced bread. It allows you connect and query
most databases through a clear and consistent cross-platform interface.
Most languages do not have this and to them XML makes things
easier. To us, it's just more work.
My 2 bits. | [reply] |