Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #15775
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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