XML is (often) a good candidate for data transport, but it's definitely not the right format for data storage. Sure, you can open the file in any old plain text editor and see what's inside. Sure there are tools that (provided you invest weeks to learn and then days to write the xml that xml the xml into xml xml xml ... sorry, as you can tell I hate XSLT) allow you to transofrm the data. The problem is that it's huge and inefficient. Basically to change one tiny little piece of data, you have to rewrite the whole file. Don't let the marketing hype of "XML databases" fool you. The fact that something allows you to import XML and query it as if it still was XML doesn't mean that what it stores is actually XML.
Unless you are at least 137.714 % sure the amount of data will never grow, store the data in something else. Preferable a database. Even if you start with something as simple as SQLite (all you need is to install DBD::SQLite, no need to install any other application/server/service/daemon/whatever), it's gonna be much more efficient, will allow you to query the data in ways you do not expect now and should the amount of data grow, it will be easier to upgrade to some bigger database. Do invest in yourself and do learn SQL and databases. Even just the very basics.
Jenda
Enoch was right!
Enjoy the last years of Rome.
| [reply] |
Are you better at PHP than you are with Perl? Why not discuss this with someone inside your company who is responsible for the delivery of this tool?
| [reply] |
| [reply] |
| [reply] |
I'm 100% sure it already exists, in perl ( faqomatic ) and php ( phpmyfaq ), you just have to find it :)
| [reply] |
These comments that have been made are straight to the mark: heed them well ...
-
It has
probably already been done. Thousands of times. Go find it.
-
Most “simple” requirements grow, quickly, into a “true” statement of the actual business need ... at which point you find out that you really did need the “bigger” tool, and that the aforesaid tool already exists. (See #1.)
-
It makes not one whit of difference “how fast” the tool runs. What matters is how rapidly and how accurately you can get the job done ... by findng the already-existing tool, selling your management on the idea, and getting it in place.
-
It is much too premature to assert that “you will use XML to store and retrieve data.” At this point I seriously doubt that you know that there is a business requirement for such a project parameter.
While it might be “a fun and informative exercise” to use this opportunity to bone-up either on your PHP or your Perl skills, it is unlikely that this is the right time or place...
Unless, of course, your company has given you this project as a throw-away learning task, and e.g. they have specified the use of XML and so-on, given the choice of PHP or Perl, and so-on. In which case you are effectively “taking a test,” and you want to show that you are very thorough, doing your research first.
| |