Main contents
Archive for May 2009
May 18th, 2009
A friend of mine, Niko, has just written a blog posting about the horrors of relational databases. and very right he is too.
i would however want to say a few words to explain how it got that way. to start with, databases must have just been better card index systems. they promised to solve problems like concurrent access to data that had traditionally been kept at one place. this was possible (provided the word concurrency could be defined to everybody’s satisfaction), because computers are good at that sort of thing. actually a system of mirrors hanging from the roof in the public library would maybe have also allowed concurrent access to information about which books are currently available and which aren’t.
back in those days of course, being a librarian and knowing how best to index and find books was a real skill. it still is of course. just nowadays instead of having a clever librarian with the ability to perform one operation a second, we have a pretty stupid one with the ability to perform many operations a second. but i digress.
so databases were used to store information. because the real world likes to store information in little one dimensional (more or less well hashed) hunks, relational databases did a great job of modelling this. things really went pair shaped when two things happened:
- object-oriented programming came into fashion
- databases started being used to store program state
now objects can have very complicated internal relationships. relational databases are not good at storing internal relationships. to start with, you need lots of tables and then you need lots of inner joins to actually get information out of them. and updating a relationship can take a long time, if lots of objects are effected or, alternatively, relationship tables need to grow according to the square of the number of lines in the tables. and all those inner join … on … having … where … etc. take a lot of time.
so object-databases are good at storing state in modern programs (and that includes most webpages). only if you really would use a card index system to store this information irl should you consider a relational database.
Posted in Uncategorized | 2 Comments »
May 9th, 2009
there’s something very weird about apache, php/perl/python/whatever, and *sql as a web server.
let’s say you have an internet site like ebay. there are many hundreds of connections at any one moment. each page call results in opening, reading and parsing a session file and then opening a connection to a database and getting the results of a few database queries (quite possibly with long sql statements). then you have to chuck all the stuff together and stir it around a bit and send it back to the client. then you have to write out the session to disk again.
now let’s say the web server has to do that 100 times a second.
at least, that’s what the basic idea is. as it is, no web server actually does this again, or the operating system saves it from itself. the database is almost certainly held in ram, so is the session cache. apache can also cache parts of often used pages, if i remember correctly.
but the basic idea stands. it is quite possible that your session has to be read from disc or that your database query requires stuff to be read from disc (that quite apart from the snake oil sql databases sell).
so why not keep the php (or whatever) instance running all the time with your objects in its cache? why not have an object cache with a root object like this:
$root=new Object();
foreach ($sessids as $sessid) {
$root->sessid=new Object();
}
but what is the difference between the information stored in the database and the information stored in the session cache? well the database just contains objects which should be shared among all sessions, so you could also add a
$root->shared=new Object()
to the root object.
then you can save
$root->shared
to disk every now and then, to guarantee persistence in case the server crashes.
of course, i’m not the first person to have thought of this. the seaside folks already do this in their product. maybe i’ll write something similar for ruby/python/php at some stage, because it would make life so much easier.
Posted in Uncategorized | No Comments »
May 9th, 2009
hi everybody 
i’ve just started looking at the prelude of the 4th english suite by j.s. bach. it’s an interesting work and i thought i’d share some of my thoughts.
firstly the basic structure of the piece. like the prelude of the second english suite (and to an extent the third, which is rather more episodic in character), the basic form is ABA. interesting is the brevity of the A section, which amounts to 19 (20) bars. the piece has a total length of 108 bars, meaning that the B section is more than three times as long as the A section.
the two sections have different melodic styles. the A section is more like the first theme of a sonata, with a rising melody. here the counterpoint rarely consists of parallel thirds or sixths. instead bach stresses the major beats as being harmonic, with the remaining space between the beats being filled with 16th notes or dotted rhythms which rarely result in parallel movement. the B section is different, starting as it does with a new theme made of 8th notes in parallel thirds.
most melodic ideas in the piece work as leading phrases. both themes of the counterpoint in the A section lead into the first beat of a bar. the first theme in 16th notes consists of a rising 15 note lead in followed by two 8th notes establishing the tonic. the second theme (which follows directly and acts as a counterpoint for the first theme) is a melodically static theme made of dotted rhythms with some decoration (mordants and trills). harmonically, apart from one interrupted cadence before the full cadence at the end of the section, there is no hint of a minor key in section A.
section B starts with a reduction in pace. whereas in section A the 16th notes had melodic significance, here they are used in an alberti fashion, resulting in movement as 8th notes. this is also a falling melody. the effect is of a second subject in sonata form, traditionally described as feminine. another idea in section B, and probably the most attractive idea by first listening, is made by the repeated 8th notes chords with suspensions and accompaniment by broken chords. these establish a strong half note speed for harmonic progressions. this impression is reinforced with a further melodic idea bach introduces (found at the end of bar 28 up to the start of bar 31 in the treble), which bach harmonises with half note speed harmonics resulting in strong suspensions on the 7th with (delayed) upwards resolution. the first few times this comes it moves upwards. later bach inverts it to great harmonic effect.
oops, gotta go. maybe i’ll continue this later.
Posted in Hobbies | No Comments »