Figuring out the most effective way for a custom database server (PHP)

I just came across the idea of writing a special database which will fit for exactly one purpose. I have looked i开发者_运维问答nto several other database-systems and came to the conclusion that I need a custom type. However my question is not about if it is a good idea, but how to implement this best.

The application itself is written in php and needs to write to a custom database system. Because there can be simultaneous read/write operations I can forget the idea of implementing the database directly into my application. (correct me please if I'm wrong).

That means I have to create 2 scripts:

1. The database-server-script
2. The application.

This means that the application has to communicate with the server. My idea was using php in cli mode for the database-server. The question is, if this is effective, or if I should look into a programming language like c++ to develop the server application? The second question is then the communication. When using php in cli mode I thought about giving a serialized-array-query as a param. When using c++ should I still do it serialized? or maybe in json, or whatever?

I have to note that a database to search through can consist of several thousands of entries. So i dont know exactly if php is realy the right choice. Secondly i have to note that queries arent strings which have to be parsed, but an array giving a key,value filter or dataset. The only maybe complexer thing the database server has to be able to is to compare strings like the MySQL version of LIKE '%VALUE%', which could be slow at several thousand entries.

Thanks for the Help.

---

writing a special database which will fit for exactly one purpose

I presume you mean a custom database management system,

I'm having a lot of trouble undertanding why this would ever be necessary.

Datasbes and Tables like usual databases have. But i dont have columns. Each entry can have its own columns, except for the id

That's not a very good reason for putting yourself (and your users) through a great deal of pain and effort.

i could use mysql id | serialized data... but then much fun searching over a specific parameter in a entry

So what's wrong with a fully polymorphic model implemented on top of a relational database:

CREATE TABLE relation (
   id INTEGER NOT NULL auto_increment,
   ....
   PRIMARY KEY (id)
);
CREATE TABLE col_string (
   relation_id NOT NULL /* references relation.id */
   name VARCHAR(20),
   val_string VARCHAR(40),
   PRIMARY KEY (relation_id, name)
);
CREATE TABLE col_integer (
   relation_id NOT NULL /* references relation.id */
   name VARCHAR(20),
   val_integer INTEGER,
   PRIMARY KEY (relation_id, name)
);
CREATE TABLE col_float (
   relation_id NOT NULL /* references relation.id */
   name VARCHAR(20),
   val_float INTEGER,
   PRIMARY KEY (relation_id, name)
);

... and tables for BLOBs, DATEs, etc

Or if scalability is not a big problem....

CREATE TABLE all_cols (
   relation_id NOT NULL /* references relation.id */
   name VARCHAR(20),
   ctype ENUM('string','integer','float',...),
   val_string VARCHAR(40),
   val_integer INTEGER,
   val_float INTEGER,
   ...
   PRIMARY KEY (relation_id, name)
);

Yes, inserts and selecting 'rows' is more complicated than for a normal relational table - but a lot simpler than writing your own DBMS from scratch. And you can wrap most of the functionality in stored procedures. The method described would also map easily to a NoSQL db.