I decided to use DBM (file-based key:value pairs) as the backend for a simple Digg-like rating system. I could implement it more quickly in DBM than in SQL, I saw no short-term need for any of SQL's features, and DBM is a tried-and-tested technology that has worked well for close to thirty years.

The first few hours of development were done in Perl since it comes standard with DBM, but I decided to choose a different language after needing to hit CPAN to gather additional libraries like JSON, considering that there is no guarantee that my host will have these libraries pre-installed or that the server configuration would allow me to use them from my user directory. Also, even if I were allowed to install libraries on the system, there is no guarantee that they would build; CPAN libraries fail to build often enough on my own system, where I am root and can install any prerequisites, that I consider the whole of perl's third-party libraries to be unreliable.

Instead, I decided to use PHP because it comes with all that stuff standard and it would just work. Indeed, it worked until I tried to deploy it. Of the four web server hosts that I have access to, none of them has php with built-in dba (what php calls dbm). It has to be compiled in, and the php package maintainers did not include it. Make that five hosts, counting half of my development system: Mint's php supports dba, but xampp on the Windows side does not.

My solution was to hack up my own dba functions to store and retrieve json k:v pairs. It's quicker than porting back to perl and rolling the dice on library support.


DBM is nice if you only need to store and retrieve key/value data and you don't need to join any tables. Need a tree hierarchy? Just use the file system.


Is the "NoSQL" hype just bullshyte for DBM?


PHP stupidity: file_put_contents() fails when the same process has a lock on the file. The combination of ftruncate(), fseek(), and fwrite() works.

file_get_contents() similarly fails. Replacement: $contents = filesize($path) ? fread($fh, filesize($path)) : "";


PHP stupidity: var_export() reports valid open file handles as NULL.


For a complete change of subject, seen on freenode #defocus:

spocky: those who do not learn from the pabst are doomed to repeat it

The other day I had a wild idea about database design.

Indexes should be on constraints rather than on columns.

It just so happens that equality (select where x=y) is the most commonly needed constraint, so conventional indexes work for most needs.

What new features could be added to a database engine with this concept in mind? Read more... )

Page generated May. 29th, 2017 07:08 pm
Powered by Dreamwidth Studios