Database written in PHP

[James Harris]

Are there any lightweight databases written in PHP?

I don't mean PHP code to access a database like MySQL or similar. I am
thinking of the data being stored in a flat file or files and there
being some PHP code to provide database-like read-write access to the
data. It does not need to be SQL-based as long as it has reasonable data
access primitives.

Maybe there are a few of these but web searches tend to pull up lots of
info on how to access a database from within PHP which is a different,
and far more common, topic. Hence, this query.

James

[Jerry Stuckle]

I haven't heard of any general purpose databases like you describe, nor
would I expect to. Anything like that is typically application
dependent. A general purpose database in PHP would be pretty slow.

What is the problem you're trying to solve?

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Jerry Stuckle]

On 10/23/2015 6:14 PM, Tim Streater wrote:
> In article <n0e8gq$stv$1...@dont-email.me>, James Harris

> SQLite, which has a nice PHP interface.
>

SQLite is not written in PHP.

[J.O. Aho]

First google result I got was: https://code.google.com/p/yndb

Third result was: http://gladius.sourceforge.net

Fourth:
http://www.phpclasses.org/package/1672-PHP-File-based-database-SQL-engine-in-pure-PHP.html

There are a number of them, how well they work, no clue.

--

//Aho

[James Harris]

What was your search query?

James

[James Harris]

On 23/10/2015 23:04, Jerry Stuckle wrote:
> On 10/23/2015 5:25 PM, James Harris wrote:
>> Are there any lightweight databases written in PHP?
>>
>> I don't mean PHP code to access a database like MySQL or similar. I am
>> thinking of the data being stored in a flat file or files and there
>> being some PHP code to provide database-like read-write access to the
>> data. It does not need to be SQL-based as long as it has reasonable data
>> access primitives.
>>
>> Maybe there are a few of these but web searches tend to pull up lots of
>> info on how to access a database from within PHP which is a different,
>> and far more common, topic. Hence, this query.

...

> I haven't heard of any general purpose databases like you describe, nor
> would I expect to. Anything like that is typically application
> dependent. A general purpose database in PHP would be pretty slow.

Maybe not for small datasets, if the comments against the packages that
J O Aho pointed to are anything to go by.

> What is the problem you're trying to solve?

No one specific but it occurred to me that a file-based database would
have some advantages:

wouldn't require a full (heavyweight) database implementation
wouldn't depend on a hosting provider providing one
wouldn't be affected by query rate limiting
could have own security model
could have own data-naming model
would, for me, make site replication easier

To explain that last point, I have a neat solution to push updates from
a private server to a public site but I have to apply database updates
separately. It would be more convenient to do all as file pushes.

Re. the security model, I have one very good provider from which I get
all the facilities I want BUT they require the database password to be
the one I log in with. So I have to leave that password stored on the
server somewhere - which I don't like doing for security reasons.

Re. the query rate limiting, some hosting services provide everything
free but in the small print they say that if your site issues too many
database queries per unit time then you will be out of terms of the free
service. As I cannot control how often the pages are accessed that
limitation is a concern.

Things like that.

James

[James Harris]

On 24/10/2015 10:30, Tim Streater wrote:
> In article <n0ecrp$ik4$1...@dont-email.me>, Jerry Stuckle

> <jstu...@attglobal.net> wrote:
>
>> On 10/23/2015 6:14 PM, Tim Streater wrote:
>>> In article <n0e8gq$stv$1...@dont-email.me>, James Harris
>>> <james.h...@gmail.com> wrote:
>>>
>>>> Are there any lightweight databases written in PHP?

...

>>> SQLite, which has a nice PHP interface.
>
>> SQLite is not written in PHP.
>

> So? Why would anyone bother to write a db engine in PHP, when there are
> plenty out there already, with interfaces from PHP to the engine?

Have given answers to that in a separate post.

> Perhaps the OP doesn't know what he's talking about.

Or perhaps you didn't understand the original query.... ;-)

James

[J.O. Aho]

Database engine written in php

--

//Aho

[Jerry Stuckle]

Not all database engines are heavyweight. But those that are are that
for a reason. Making a reliable database engine is not a minor matter.
I looked at the ones J.O. pointed out, and I see nothing that will
prevent data corruption by such things as concurrent updates from
multiple applications. Now maybe that's not important to you, but it is
to anyone who cares about their site it should be. Plus, I still don't
see any performance comparisons for them - but they are going to be much
slower than any SQL database written in a compiled language.

As for your hosting provider not providing one - a total red herring.
You have to depend on the hosting provider for a lot of things - the web
server, PHP and other things. Plus, every hosting provider has a SQL
engine nowadays - MySQL is the most common.

And I don't know of anyone who limits query rates - at least not amongst
the non-free companies. And the query rate of your PHP database is
probably going to be slower than that set by even the free hosting
companies. Plus, if you do have a hosting company who limits the query
rate, it's going to be to limit the load on the server - and your PHP
database is going to load the server more than a real database engine does.

Is the security model important? Do these even have a security model?
If you are concerned about security, you should be looking for an engine
which stores the data outside of user space where it's safe; if you can
access the files themselves, then others potentially can, also.

But now we get down to the real reason - you think it will make your
replication easier. Replicating a database is not hard; on my sites I
do it automatically once a day for backup. It's a one line command for
each database (I could back up all of them in one line but restoring a
single database would be harder). And if I have to restore a database,
again, one line. Not hard at all.

[James Harris]

It's not just the need for reliability that will make a database engine
large. They also have many facilities such as for value
checking/vetting, table joins, SQL parsing and optimising, different
access methods etc. And each new version of a database accretes
additional code for new features.

As you say, there will be good reasons for the size of the code but very
little of it will be used in most cases. To make an analogy you don't
need a copy of the OED if you just want to look up normal words. You
don't say that the OED is that large for a reason and therefore it is
the one to use.

I haven't timed the traditional access process but consider these steps

1. Get an authenticated connection. DB checks credentials

2. Send a query string. (Let's assume that the string already has fields
filled in.) DB parses the query string checking that it is well formed
and that the tables mentioned therein are valid. DB (hopefully)
generates an optimised form of the search query by looking at
information about the tables mentioned: whether they have an index, what
fields are indexed, and how many records are in the table.

3. DB runs the query by accessing files and forms a reply object which
contains the rows in some form for which the fields are accessible.

4. PHP takes the DB reply and converts it to a PHP object, along with
making sure that the fields of a row are accessible by key or index or
whatever.

5. The requesting code checks the reply object and accesses the content
therein.

The above is fine for large datasets. But sometimes what I want to do is
access a piece of stored data by a simple key. For that, the above is
overkill.

By contrast, to get the same piece of data from a flat file I would just
access a file (a simplified form of step 3 of the above).

Perhaps the issue is not just the size of the engine but that MySQL and
its ilk are based on tables whereas what is sometimes wanted is a simple
key-value store. (The stored values could be scalars or tables or even
tables modified by query strings which select certain columns and rows.)

> I looked at the ones J.O. pointed out, and I see nothing that will
> prevent data corruption by such things as concurrent updates from
> multiple applications. Now maybe that's not important to you, but it is
> to anyone who cares about their site it should be. Plus, I still don't
> see any performance comparisons for them - but they are going to be much
> slower than any SQL database written in a compiled language.

From their descriptions I too am not sure that any are suitable
(although having them pointed out was welcome).

> As for your hosting provider not providing one - a total red herring.
> You have to depend on the hosting provider for a lot of things - the web
> server, PHP and other things. Plus, every hosting provider has a SQL
> engine nowadays - MySQL is the most common.

Yes, that's probably valid.

> And I don't know of anyone who limits query rates - at least not amongst
> the non-free companies. And the query rate of your PHP database is
> probably going to be slower than that set by even the free hosting
> companies. Plus, if you do have a hosting company who limits the query
> rate, it's going to be to limit the load on the server - and your PHP
> database is going to load the server more than a real database engine does.

If you want to set up a site for a special-interest group you might find
that no one wants to pay a subscription to keep the site going. In that
case a free hosting solution is ideal but you have to work with the
limitations of the provider.

That said, those limitations are not very onerous. I found one which had
PHP and MySQL as normal and also allowed URL rewriting which was a
distinct benefit. But they had/have a limit on DB queries per second. I
don't know the sanction if you exceed the limit but they may require an
upgrade to a paid service which would effectively kill the site.

> Is the security model important? Do these even have a security model?
> If you are concerned about security, you should be looking for an engine
> which stores the data outside of user space where it's safe; if you can
> access the files themselves, then others potentially can, also.

Well, the problem I mentioned before was having to use the site's
password to access the database - even for data that did not need to be
secured. The security flaw there was having to use a password in the
code or something accessed therefrom.

> But now we get down to the real reason - you think it will make your
> replication easier. Replicating a database is not hard; on my sites I
> do it automatically once a day for backup. It's a one line command for
> each database (I could back up all of them in one line but restoring a
> single database would be harder). And if I have to restore a database,
> again, one line. Not hard at all.

I don't know why you would think this is the "real" reason. Are you some
sort of mind reader? *All* the reasons I gave were valid and relevant.

James

[J.O. Aho]

On 10/24/2015 04:58 PM, Jerry Stuckle wrote:

> Not all database engines are heavyweight. But those that are are that
> for a reason. Making a reliable database engine is not a minor matter.
> I looked at the ones J.O. pointed out, and I see nothing that will
> prevent data corruption by such things as concurrent updates from
> multiple applications. Now maybe that's not important to you, but it is
> to anyone who cares about their site it should be. Plus, I still don't
> see any performance comparisons for them - but they are going to be much
> slower than any SQL database written in a compiled language.

I wouldn't see any of them as something to be used in a production
environment, they are more proof of concept, that you can write a
database engine in PHP and learn the basics before moving toward
contributor for say MariaDB.

--

//Aho

[Jerry Stuckle]

Which would be true of any general purpose database, no matter what the
language it is written in.

> As you say, there will be good reasons for the size of the code but very
> little of it will be used in most cases. To make an analogy you don't
> need a copy of the OED if you just want to look up normal words. You
> don't say that the OED is that large for a reason and therefore it is
> the one to use.
>

Which is immaterial when you're sharing the same code with a couple of
hundred other users.

> I haven't timed the traditional access process but consider these steps
>
> 1. Get an authenticated connection. DB checks credentials
>
> 2. Send a query string. (Let's assume that the string already has fields
> filled in.) DB parses the query string checking that it is well formed
> and that the tables mentioned therein are valid. DB (hopefully)
> generates an optimised form of the search query by looking at
> information about the tables mentioned: whether they have an index, what
> fields are indexed, and how many records are in the table.
>
> 3. DB runs the query by accessing files and forms a reply object which
> contains the rows in some form for which the fields are accessible.
>
> 4. PHP takes the DB reply and converts it to a PHP object, along with
> making sure that the fields of a row are accessible by key or index or
> whatever.
>
> 5. The requesting code checks the reply object and accesses the content
> therein.
>
> The above is fine for large datasets. But sometimes what I want to do is
> access a piece of stored data by a simple key. For that, the above is
> overkill.
>

And every step has to be performed by any general-purpose database
engine, no matter what the size of the dataset.

> By contrast, to get the same piece of data from a flat file I would just
> access a file (a simplified form of step 3 of the above).
>

Then set up your own code to work on a flat file.

> Perhaps the issue is not just the size of the engine but that MySQL and
> its ilk are based on tables whereas what is sometimes wanted is a simple
> key-value store. (The stored values could be scalars or tables or even
> tables modified by query strings which select certain columns and rows.)
>

Then set up your own code to work on a flat file.

>> I looked at the ones J.O. pointed out, and I see nothing that will
>> prevent data corruption by such things as concurrent updates from
>> multiple applications. Now maybe that's not important to you, but it is
>> to anyone who cares about their site it should be. Plus, I still don't
>> see any performance comparisons for them - but they are going to be much
>> slower than any SQL database written in a compiled language.
>
> From their descriptions I too am not sure that any are suitable
> (although having them pointed out was welcome).
>

No, like J.O., I would never use any in a production environment.

>> As for your hosting provider not providing one - a total red herring.
>> You have to depend on the hosting provider for a lot of things - the web
>> server, PHP and other things. Plus, every hosting provider has a SQL
>> engine nowadays - MySQL is the most common.
>
> Yes, that's probably valid.
>

It is valid - any hosting company without a SQL database nowadays
wouldn't last long due to the lack of customers.

>> And I don't know of anyone who limits query rates - at least not amongst
>> the non-free companies. And the query rate of your PHP database is
>> probably going to be slower than that set by even the free hosting
>> companies. Plus, if you do have a hosting company who limits the query
>> rate, it's going to be to limit the load on the server - and your PHP
>> database is going to load the server more than a real database engine
>> does.
>
> If you want to set up a site for a special-interest group you might find
> that no one wants to pay a subscription to keep the site going. In that
> case a free hosting solution is ideal but you have to work with the
> limitations of the provider.
>

I've run several of them over the years, all at my own expense. You can
get decent hosting for around $50/yr. If that's too much for you, then
the site isn't very important.

I'm down to one free organization now, but I'm running my own servers,
so all it's costing me is a bit of space and bandwidth.

> That said, those limitations are not very onerous. I found one which had
> PHP and MySQL as normal and also allowed URL rewriting which was a
> distinct benefit. But they had/have a limit on DB queries per second. I
> don't know the sanction if you exceed the limit but they may require an
> upgrade to a paid service which would effectively kill the site.
>

You get what you pay for.

>> Is the security model important? Do these even have a security model?
>> If you are concerned about security, you should be looking for an engine
>> which stores the data outside of user space where it's safe; if you can
>> access the files themselves, then others potentially can, also.
>
> Well, the problem I mentioned before was having to use the site's
> password to access the database - even for data that did not need to be
> secured. The security flaw there was having to use a password in the
> code or something accessed therefrom.
>

Yes, you need a password in the code. Actually, I never put it in the
code; I put it in a file which resides outside of the website hierarchy,
and include it where necessary.

No security is perfect - but it's better than no security, which is what
you're proposing.

>> But now we get down to the real reason - you think it will make your
>> replication easier. Replicating a database is not hard; on my sites I
>> do it automatically once a day for backup. It's a one line command for
>> each database (I could back up all of them in one line but restoring a
>> single database would be harder). And if I have to restore a database,
>> again, one line. Not hard at all.
>
> I don't know why you would think this is the "real" reason. Are you some
> sort of mind reader? *All* the reasons I gave were valid and relevant.
>
> James
>
>

Nope, the only "valid" reason is that you're too lazy to do it right.
All of the others are red herrings.

[Erwin Moller]

Keep in mind Google delivers wildly different result because of that
damned personalization trend. (Filter Bubble).
I might get different results than you do.

https://en.wikipedia.org/wiki/Filter_bubble

I also recommend this great Ted talk:
https://www.ted.com/talks/eli_pariser_beware_online_filter_bubbles?language=en



Regards,
Erwin Moller

--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens

[Matthew Carter]

Use something like DuckDuckGo to avoid that (also shows yndb as first
result and gladius a couple results down).

--
Matthew Carter (m...@ahungry.com)
http://ahungry.com

[Erwin Moller]

On 10/24/2015 12:47 PM, Tim Streater wrote:
> In article <n0fn5k$66d$1...@dont-email.me>, James Harris

> <james.h...@gmail.com> wrote:
>
>> On 24/10/2015 10:30, Tim Streater wrote:
>>> In article <n0ecrp$ik4$1...@dont-email.me>, Jerry Stuckle
>>> <jstu...@attglobal.net> wrote:
>>>
>>>> On 10/23/2015 6:14 PM, Tim Streater wrote:
>>>>> In article <n0e8gq$stv$1...@dont-email.me>, James Harris
>>>>> <james.h...@gmail.com> wrote:
>>>>>
>>>>>> Are there any lightweight databases written in PHP?
>

>>>>> SQLite, which has a nice PHP interface.
>>>
>>>> SQLite is not written in PHP.
>>>
>>> So? Why would anyone bother to write a db engine in PHP, when there are
>>> plenty out there already, with interfaces from PHP to the engine?
>>
>> Have given answers to that in a separate post.
>>
>>> Perhaps the OP doesn't know what he's talking about.
>>
>> Or perhaps you didn't understand the original query.... ;-)
>

> SQLite *is* a lightweight database; it doesn't have a server and its
> code is compiled into the application. I use it in my (PHP-based)
> application, and it's perfectly adequate (also any question of a "limit
> to the number of database queries that can be issued" doesn't arise).
>
> It can be considered essentially as a replacement for fopen/fclose,
> fread/fwrite.
>

Read the original question, please.
The OP isn't asking for only a lightweight database, he inquires about
one WRITTEN IN PHP. Not just "to be used with PHP".

[robamm...@hotmail.com]

Hello James!

I was searching for the same....But I did not find anything, that works.
So I started to develop my own.

If you are still interested, then try my version(Simple object based php database system, that saves data to files and is includable in application(or webpage)): https://groups.google.com/forum/#!topic/internet-biz07/tKpz-vP9Z-U


With best wishes,
Kristjan Robam

[Arno Welzel]

Tim Streater:

> In article <2f8c9bff-1c33-41b8...@googlegroups.com>,
> <robamm...@hotmail.com> wrote:
[...]

>> If you are still interested, then try my version(Simple object based php
>> database system, that saves data to files and is includable in application(or
>> webpage)): https://groups.google.com/forum/#!topic/internet-biz07/tKpz-vP9Z-U
>

> Have you not looked at SQLite? That seems to me to be what you need.

Personally I would also always recommend using SQLite if MySQL etc. is
not possible. However - beside the fact the the original post is already
more than 4(!) years old, the OP asked for a solution which does not
need any extensions like SQLite.

--
Arno Welzel
https://arnowelzel.de

[mina...@gmail.com]

If somebody thinks he/she will need it then he/she can give a try(I just updated the code 8 minutes ago on that link ). When posting, then it is not so important, that the answer refers to the exact date. People, who are looking the same, will first look it from usenet and then will ask. If they find it, then they will not ask.

Best wishes,
Kristjan Robam
Tel: 372 6861327
E-mail: kri st jan 12 9 1983 @ gm ai l. co m
or
rob am ma n @ ho t ma il .c o m
(Please remove empty characters)

[J.O. Aho]

On 02/04/2020 17.00, Arno Welzel wrote:

> beside the fact the the original post is already
> more than 4(!) years old,

It's an issue with google news, people who uses it don't care about post
dates, they just think they found another web forum online.

--

//Aho

[mina...@gmail.com]

They should care about post dates. To get the latest stuff.

[J.O. Aho]

On 15/04/2020 09.35, mina...@gmail.com wrote:
> kolmapäev, 15. aprill 2020 9:04.13 UTC+3 kirjutas J.O. Aho:
>> On 02/04/2020 17.00, Arno Welzel wrote:
>>
>>> beside the fact the the original post is already
>>> more than 4(!) years old,
>>
>> It's an issue with google news, people who uses it don't care about post
>> dates, they just think they found another web forum online.
>

> They should care about post dates. To get the latest stuff.

They don't, they keep on replying to posts that are 10 years old.

Also they don't care about removing signatures, guess it's googles fault
as they don't have support to cut messages when they find
dash-dash-space as the only data in a line.

They tend to forget to add the dash-dash-space on the line before the
huge signature.

--

//Aho

[Man From a city with name Viljandi]

J.O. Aho kirjutas kolmapäev, 15. aprill 2020 kl 14:14:57 UTC+3:
> On 15/04/2020 09.35, mina...@gmail.com wrote:
> > kolmapäev, 15. aprill 2020 9:04.13 UTC+3 kirjutas J.O. Aho:
> >> On 02/04/2020 17.00, Arno Welzel wrote:
> >>
> >>> beside the fact the the original post is already
> >>> more than 4(!) years old,
> >>
> >> It's an issue with google news, people who uses it don't care about post
> >> dates, they just think they found another web forum online.
> >
> > They should care about post dates. To get the latest stuff.
> They don't, they keep on replying to posts that are 10 years old.
>

Sometimes it may be useful. When some idea gets a good development.





With the best wishes,
Your all very good friend.

Telephone: 372 6861327
E-mail: ya12983 @@ mail com