I cut my description of the website short in my previous post, as it was, after all, my first post. Now, however, I feel I can talk about slinki. What is slinki? It is my "proprietary" database system.
Most database systems are based around a table-record-column paradigm. Though this form can be useful and simple, it can also be limiting. About a year ago I was working on a website, and trying to build a rather complicated page for it. The site was a portal, and I was trying to make a single page which showed for a user all records which he or she modified on the site. For instance, it should list all forum posts added, all wiki articles modified, and other various things.
The problem was that each kind of item had its own record type in its own table, and combining these was quite a task. Of course, it is possible, but a custom handler must be made for each different row type, and it can be quite time consuming.
Over the past year I have continuously been working on ways to get around these difficulties, and my database system, which I have dubbed "slinki", seems to do just that. slinki (which must always start with a lower case letter) can be difficult to get used to, but it is extremely powerful. This site is, in fact, based upon it.
slinki is a tableless system. Almost all data in the database consists of items and links between them. This has many benefits, though it can also have some performance setbacks. Primarily, this allows for all objects to be alike where they are alike, and different where they are different. For instance, items in a gallery may be exactly like items in a blog, except for a couple image-oriented properties. In slinki, a blog post and a gallery image are both simply items, which are connected to sub-items which hold the properties relating to them. In fact, blog entries and gallery items in my site are not even typed, meaning there is almost nothing setting apart an image from a blog post. The only reason they display differently is because of where the user navigated from.
One example of this feature are the "blog in images" and "recent gallery additions" sections which are omnipresent on the left of the screen. These two sections use exactly the same code, yet one shows pictures from blog posts while the other shows pictures from the gallery.
To further emphasize how close blog entries are to gallery entries, go to an image in the gallery and then click on one of the pictures under "blog in images." It will appear in the gallery, just like a gallery image! In fact, just by changing a value in a drop-down list box, I can change the blog into a gallery (an exercise which, while interesting, would make the blog rather less like a blog.)
However, the system does have its drawbacks. Doing a query can be extremely taxing for the system, which is built upon MySQL (three tables, plus one extra which I really shouldn't need but do for now, and a few others which are tables I should dispose of). Every separate piece of text would usually need a separate query to retrieve. A single blog post could take 10+ queries! Fortunately, I have managed to combine multiple strings into one query (using a technique I call prefetching). I have not fully implemented prefetching yet, however. Doing so, though, could drastically improve performance (which by my tests already on-par with an out-of-the-box Wordpress)
The most important factor in keeping the site up to speed, however, is caching. I use APC heavily, and tons of data is stored there (if everything works as planned, the whole database is stored there!). Unfortunately, I still require more cache hits than I would like (due to lack of prefetching). At some point I plan to add output caching, which would really really increase the performance of the site. In theory it isn't too complicated, as the same methods I use to see if something has been updated in any other part of the cache can be used here as well.
My caching system will probably also start having problems when/if it runs out of space, as parts of the cache is used specifically to determine whether or not something needs to be refreshed. My caching system is an active caching system, meaning that it updates the cache items as values are updated. I'd prefer a lazy system, but due to speed issues this is impractical: each cache request would need to be checked for validity, and there can be hundreds and sometimes even thousands of cache queries per page. Again, prefetching can help this, but for now, an active system is the only way to maintain a good speed..
At some point it may be possible to create a custom database server which would eliminate the need for such a caching system. I do have some plans for one, but I've never really built any kind of server, so...