Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #15760 > unrolled thread

Database written in PHP

Back to article view | Back to comp.lang.php

Contents

  Database written in PHP James Harris <james.harris.1@gmail.com> - 2015-10-23 22:25 +0100
    Re: Database written in PHP Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-23 18:04 -0400
      Re: Database written in PHP James Harris <james.harris.1@gmail.com> - 2015-10-24 11:37 +0100
        Re: Database written in PHP Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-24 10:58 -0400
          Re: Database written in PHP James Harris <james.harris.1@gmail.com> - 2015-10-24 17:07 +0100
            Re: Database written in PHP Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-24 15:12 -0400
          Re: Database written in PHP "J.O. Aho" <user@example.net> - 2015-10-24 19:15 +0200
    Re: Database written in PHP Tim Streater <timstreater@greenbee.net> - 2015-10-23 23:14 +0100
      Re: Database written in PHP Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-23 18:40 -0400
        Re: Database written in PHP Tim Streater <timstreater@greenbee.net> - 2015-10-24 10:30 +0100
          Re: Database written in PHP James Harris <james.harris.1@gmail.com> - 2015-10-24 11:41 +0100
            Re: Database written in PHP Tim Streater <timstreater@greenbee.net> - 2015-10-24 11:47 +0100
              Re: Database written in PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-10-30 11:26 +0100
                Re: Database written in PHP Tim Streater <timstreater@greenbee.net> - 2015-10-30 10:42 +0000
    Re: Database written in PHP "J.O. Aho" <user@example.net> - 2015-10-24 09:21 +0200
      Re: Database written in PHP James Harris <james.harris.1@gmail.com> - 2015-10-24 11:23 +0100
        Re: Database written in PHP "J.O. Aho" <user@example.net> - 2015-10-24 14:35 +0200
          Re: Database written in PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-10-29 17:05 +0100
            Re: Database written in PHP Matthew Carter <m@ahungry.com> - 2015-10-29 21:46 -0400
    Re: Database written in PHP robamman2020@hotmail.com - 2020-04-01 23:38 -0700
      Re: Database written in PHP Tim Streater <timstreater@greenbee.net> - 2020-04-02 09:01 +0100
        Re: Database written in PHP Arno Welzel <usenet@arnowelzel.de> - 2020-04-02 17:00 +0200
          Re: Database written in PHP minajaich@gmail.com - 2020-04-14 22:44 -0700
          Re: Database written in PHP "J.O. Aho" <user@example.net> - 2020-04-15 08:04 +0200
            Re: Database written in PHP minajaich@gmail.com - 2020-04-15 00:35 -0700
              Re: Database written in PHP "J.O. Aho" <user@example.net> - 2020-04-15 13:14 +0200
                Re: Database written in PHP Man From a city with name Viljandi <ya12983@mail.com> - 2021-03-29 10:31 -0700

Page 1 of 2  [1] 2  Next page →

#15760 — Database written in PHP

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

[toc] | [next] | [standalone]

#15761

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.
> 
> James
> 

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
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#15769

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

[toc] | [prev] | [next] | [standalone]

#15774

On 10/24/2015 6:37 AM, James Harris wrote:
> 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
> 

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.

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

[toc] | [prev] | [next] | [standalone]

#15775

On 24/10/2015 15:58, Jerry Stuckle wrote:
> On 10/24/2015 6:37 AM, James Harris wrote:
>> 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
>>
>
> 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.

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

[toc] | [prev] | [next] | [standalone]

#15777

On 10/24/2015 12:07 PM, James Harris wrote:
> On 24/10/2015 15:58, Jerry Stuckle wrote:
>> On 10/24/2015 6:37 AM, James Harris wrote:
>>> 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
>>>
>>
>> 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.
> 
> 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.
>

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.

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

[toc] | [prev] | [next] | [standalone]

#15776

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

[toc] | [prev] | [next] | [standalone]

#15762

In article <n0e8gq$stv$1@dont-email.me>, James Harris
<james.harris.1@gmail.com> 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.


SQLite, which has a nice PHP interface.

-- 
"Once you adopt the unix paradigm, the variants cease to be a problem - you
bitch, of course, but that's because bitching is fun, unlike M$ OS's, where 
bitching is required to keep your head from exploding." - S Stremler in afc

[toc] | [prev] | [next] | [standalone]

#15763

On 10/23/2015 6:14 PM, Tim Streater wrote:
> In article <n0e8gq$stv$1@dont-email.me>, James Harris
> <james.harris.1@gmail.com> 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.
> 
> 
> SQLite, which has a nice PHP interface.
> 

SQLite is not written in PHP.

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

[toc] | [prev] | [next] | [standalone]

#15766

In article <n0ecrp$ik4$1@dont-email.me>, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

>On 10/23/2015 6:14 PM, Tim Streater wrote:
>> In article <n0e8gq$stv$1@dont-email.me>, James Harris
>> <james.harris.1@gmail.com> 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.

>> 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?

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

-- 
"People don't buy Microsoft for quality, they buy it for compatibility
with what Bob in accounting bought last year. Trace it back - they buy
Microsoft because the IBM Selectric didn't suck much" - P Seebach, afc

[toc] | [prev] | [next] | [standalone]

#15770

On 24/10/2015 10:30, Tim Streater wrote:
> In article <n0ecrp$ik4$1@dont-email.me>, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
>
>> On 10/23/2015 6:14 PM, Tim Streater wrote:
>>> In article <n0e8gq$stv$1@dont-email.me>, James Harris
>>> <james.harris.1@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

[toc] | [prev] | [next] | [standalone]

#15771

In article <n0fn5k$66d$1@dont-email.me>, James Harris
<james.harris.1@gmail.com> wrote:

>On 24/10/2015 10:30, Tim Streater wrote:
>> In article <n0ecrp$ik4$1@dont-email.me>, Jerry Stuckle
>> <jstucklex@attglobal.net> wrote:
>>
>>> On 10/23/2015 6:14 PM, Tim Streater wrote:
>>>> In article <n0e8gq$stv$1@dont-email.me>, James Harris
>>>> <james.harris.1@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.

-- 
"Once you adopt the unix paradigm, the variants cease to be a problem - you
bitch, of course, but that's because bitching is fun, unlike M$ OS's, where 
bitching is required to keep your head from exploding." - S Stremler in afc

[toc] | [prev] | [next] | [standalone]

#15808

On 10/24/2015 12:47 PM, Tim Streater wrote:
> In article <n0fn5k$66d$1@dont-email.me>, James Harris
> <james.harris.1@gmail.com> wrote:
>
>> On 24/10/2015 10:30, Tim Streater wrote:
>>> In article <n0ecrp$ik4$1@dont-email.me>, Jerry Stuckle
>>> <jstucklex@attglobal.net> wrote:
>>>
>>>> On 10/23/2015 6:14 PM, Tim Streater wrote:
>>>>> In article <n0e8gq$stv$1@dont-email.me>, James Harris
>>>>> <james.harris.1@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".

Regards,
Erwin Moller

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

[toc] | [prev] | [next] | [standalone]

#15809

In article <563345b2$0$23829$e4fe514c@news.xs4all.nl>, Erwin Moller
<erwinmollerusenet@xs4all.nl> wrote:

>On 10/24/2015 12:47 PM, Tim Streater wrote:
>> In article <n0fn5k$66d$1@dont-email.me>, James Harris
>> <james.harris.1@gmail.com> wrote:
>>
>>> On 24/10/2015 10:30, Tim Streater wrote:
>>>> In article <n0ecrp$ik4$1@dont-email.me>, Jerry Stuckle
>>>> <jstucklex@attglobal.net> wrote:
>>>>
>>>>> On 10/23/2015 6:14 PM, Tim Streater wrote:
>>>>>> In article <n0e8gq$stv$1@dont-email.me>, James Harris
>>>>>> <james.harris.1@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".

I did read the original question. I decided to answer a different one.

-- 
Lady Astor: "If you were my husband I'd give you poison." Churchill: "If
you were my wife, I'd drink it."

[toc] | [prev] | [next] | [standalone]

#15765

On 10/23/2015 11: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.

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

[toc] | [prev] | [next] | [standalone]

#15768

On 24/10/2015 08:21, J.O. Aho wrote:
> On 10/23/2015 11: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.
>
> 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

What was your search query?

James

[toc] | [prev] | [next] | [standalone]

#15773

On 10/24/2015 12:23 PM, James Harris wrote:
> On 24/10/2015 08:21, J.O. Aho wrote:
>> On 10/23/2015 11: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.
>>
>> 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
>>
> 
> What was your search query?


Database engine written in php

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#15804

On 10/24/2015 2:35 PM, J.O. Aho wrote:
> On 10/24/2015 12:23 PM, James Harris wrote:
>> On 24/10/2015 08:21, J.O. Aho wrote:
>>> On 10/23/2015 11: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.
>>>
>>> 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
>>>
>>
>> What was your search query?
>
>
> Database engine written in php
>

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

[toc] | [prev] | [next] | [standalone]

#15806

Erwin Moller <erwinmollerusenet@xs4all.nl> writes:

> On 10/24/2015 2:35 PM, J.O. Aho wrote:
>> On 10/24/2015 12:23 PM, James Harris wrote:
>>> On 24/10/2015 08:21, J.O. Aho wrote:
>>>> On 10/23/2015 11: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.
>>>>
>>>> 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
>>>>
>>>
>>> What was your search query?
>>
>>
>> Database engine written in php
>>
>
> 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

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

[toc] | [prev] | [next] | [standalone]

#18270

laupäev, 24. oktoober 2015 0:25.56 UTC+3 kirjutas 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

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web