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


Groups > comp.lang.php > #15775

Re: Database written in PHP

From James Harris <james.harris.1@gmail.com>
Newsgroups comp.lang.php
Subject Re: Database written in PHP
Date 2015-10-24 17:07 +0100
Organization A noiseless patient Spider
Message-ID <n0ga8k$9ll$1@dont-email.me> (permalink)
References <n0e8gq$stv$1@dont-email.me> <n0eao9$aos$1@dont-email.me> <n0fmt6$5do$1@dont-email.me> <n0g66e$ppb$1@dont-email.me>

Show all headers | View raw


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

Back to comp.lang.php | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web