I want to store data and read/modify it on my Web server using Perl. I don't need something big and scary like SQL. Are there any modules or even just standard syntax for plaintext files to do this?
I have no idea why most ``content management systems'' aren't written like this. Huge MediaWiki and WordPress sites, I can understand, but you don't need MySQL for your personal web site that gets fifty hits a month.
Flat files and the existing file system work fine for HTML, they work fine for most dynamic sites too.
Name:
Anonymous2012-12-19 19:20
DBIx::Class + DBD::SQLite or DBD::DBM
There is DBD::CSV if you really want plain text, but please don't.
>>4
Concurred. And make the scripts_w/cron|daemons that update your flat HTML w/ tags to make ,,Dynamic-ish``. This is old shit, even for harmful perl.
However, when you need to archive shit, and secure it, dbs like these are awesome:
If SQL is ``big and scary'' to you just admit you're a worthless code monkey who doesn't understand relational algebra enough to design elegant schemas and queries. SQLite is incredibly lightweight, efficient and powerful.
Flat files? Are you fucking serious? Go back to cat-v dumb ass.
>>7 relational algebra enough to design elegant schemas and queries.
That was ENTERPRISE QUALITY!
Name:
Anonymous2012-12-20 0:15
>>8
Relational algebra is not a buzzword, it's a branch of logic. A flat file database requires you to traverse your table and write schema specific code that changes with your database design. It's the same brute force, unscientific and ultimately destructive code monkey approach to parsing XML in Java.
I guess you prefer bubble sort to quick sort because optimization and elegance is too ENTERPRISE for you.
Name:
Anonymous2012-12-20 0:26
SQLite is excellent, and is exactly what you're looking for.
``The AWK Programming Language'' has examples of building flat-file databases, but why would you bother when SQLite Just Works and will be far more performant?
Implying your shitty homebrewed linear search on a flat file will outperform a database system written by experts and optimised over years.
Especially something like SQLite.
Name:
Anonymous2012-12-20 4:04
>>13
More like, written by overworked code monkies, patched together when ever needed. Or in the case of open sauce, written by random clowns.
Why do you feel databases are so special, hard to grasp basic I/O and search trees?
Name:
Anonymous2012-12-20 4:15
>>14 implying you're not a random clown
You'll avoid having to write and troubleshoot a parser, your data will be more easily accessible and cross-platform, and your updates will be transactional.
Name:
Anonymous2012-12-20 4:26
>>15
Why would you want to update a value (that is destroying previous data)? That's a database trying to be the monkey, while it only should record what the monkey does. Infact I wouldn't even call it a database if it is designed to destroy data.
Name:
Anonymous2012-12-20 4:39
>>15
Why do you need a parser, for SQL? Do you need SQL? Why?
What's wrong with an imperative language and exposing the structures needed to get relevant data on the client side. You know, that might even make it possible to store the most fundamental data structure, the graph. Do you know what that is? What is a database that can not efficiently store and traverse the most fundamental data structure?
Wikipedia article on ``Critisism of science'' only links to ``Reductionism'' and ``Feminism''. Of course science is criticized by feminists as it is a male-dominated field that consistently fails to prove any female gender superiority.
>>17
The parser is for the stored data. Use the right tool for the job. For many many jobs, SQLite is the right tool. Use graphs when needed and use SQLite when needed.
>>1-18
I am going to end this. For publishing, Flat files. One simple transaction is done by the user and the server. For data management, *nix File System. SQL is fine too, but a daemon must publish from the DB the Data as flat files on a *nix FS for the publishing server.
Simple as a factory. Now the Daemon, could have AI, and make the publishing easier when a new Design is required.
Keeps everything compartmentalized and atomic.
Should have stay in gophersphere
Name:
Anonymous2012-12-20 9:01
SQL is a good choice is disaster recovery and latency don't matter to you
Riak is a good choice if latency doesn't matter to you
If you want something with disaster recovery, par data and low latency, you simply have to roll your own. There is no other way.
Name:
Anonymous2012-12-20 10:26
XML is the hipster's S-expressions
Name:
Anonymous2012-12-20 14:19
JSON is the hipster's XML
Name:
Anonymous2012-12-20 15:21
Why do you need a parser, for SQL? Do you need SQL? Why?
This is a sound argument, /prog/ must take the iniative to create BBQL, based on Shitpost Calculus.
>>24 SQL is a good choice is disaster recovery and latency don't matter to you
and scaling Riak is a good choice if latency doesn't matter to you
umena latency does matter to you, so does disaster tolerance.
anyway, i do not recommend riak anyone, because it's not for pussies but for CS academics, if one cares about consistency just a little bit.
Name:
Anonymous2012-12-20 15:54
An alternative to a database is implementing half-arsed text based serialization system which is unconsistent, non-atomic and downright scary.
>>27
I find your second example rather confusing. Do you mean to and or or the two conditions together? Is there support for such a thing? I also find your syntax rather inconsistent.