On Mar 10, 7:47*pm, wjhonson <wjhon... (AT) aol (DOT) com> wrote:
I have read this thread with great interest as it has unfolded. It's
sort of like kids watching the neighbor lady sunbathe through a whole
in the fence.

However, I have to add my nickels worth here. I didn't see it said
directly, but many times indirectly...

There's a HUGE difference in write an interface to an existing
database that has its own DBMS and writing the DBMS itself in PHP. I
would say that PHP is quite possibly the worst language to write a
DBMS in. Doing lookups it exactly what it is meant for, handling all
the back end of a DBMS is not. There's a ton of overhead in any DBMS,
record locking, file locking, multi-user access control, physical
storage and access of the data, encryption, decryption, etc. You add
all that in and write it in PHP and it will be the slowest thing you
have ever seen in you entire life. PHP is not an executable (machine)
language, it is interpreted and by it's very nature it is slow at
doing I/O. I/O is the life blood of and good DBMS. Something that
takes milliseconds in executable (machine) code can take whole seconds
even minutes in an interpreted language.

Just to aswage the barage of complaints that Pick Basic is typical
only compiled to pseudo code, I offer the fact that all the I/O is
actually execute in machine code. When you READ a record from a file
you do not have to write the low-level, read a sector off of disk and
parse into a set of records code. All of that is handled at the
machine level, not the interpreted pseudo-code level

I started to write something similar in Perl one time, then I woke
up! What nightmare! Just not the correct tool for the job. The fact
is, that connecting to an existing DBMS and requesting data is what
PHP and Perl are more suited to, not writing the DBMS itself.

Thanks for reading,

Marshall

Why would you want to write a database in php ??? any database not
just a pick style one. (actually why would you write anything new in
php - oh lets not go there tho ).

Symeon wondered:
We _dreamed_ about writing databases in PHP!

Our managers would wake us up two hours before
we went to bed so that we could write entire
Operating Systems in LISP! And in the afternoon
we'd port the entire O/S to a memory stick...

--
frosty

On Mar 12, 8:26*am, "frosty" <fros... (AT) bogus (DOT) tld> wrote:
*And in the afternoon
WOW! If you have the OS bootable from a memory stick, when you are
finished with the PHP port of Pick, I know just the competition you
could enter ....

On 11 Mar, 10:06, mlu... (AT) doxgroup (DOT) com wrote:
Then you've never worked in LISP. Quite possibly the worst language
to write anything in.

Doesn't look like a ton to me. Looks like a bucketful.
At any rate, it is not the DBMS that's doing the encryption and
decryption. The DBMS itself does not care what sort of data its
handling, provided you tell it, this is "text", this is "binary", etc.

I don't know, pretty stiff competition for the lowest rung there. One
time I wrote a continuously updating clock for a menu program, in Pick
BASIC. Brought the system to its knees, but hey it was fun to figure
out how to do it.

If you know of any web application that is processing a thousand
records a minute or something, let me know. Otherwise I just don't
see the problem here.

When you read a record in PHP you also do not have to handle reading a
sector off a disk.... I think you went overboard there. What modern
DBMS exposes the sectors to the programmer? Reading a block (frame)
in PHP is exceedingly simple, much more so than in Pick BASIC by the
way. Set your state variable and explode the contents on FF and then
again on FE and you're done. I don't see what's so hard.

Fine I wont' invite you to the coming out party then.

Will

On Mar 12, 5:12*am, wjhonson <wjhon... (AT) aol (DOT) com> wrote:

Umm.... Even at today's lowliest website one thinks in terms of
transactions per second, not minute. As for examples of websites
certainly processing more than a thousand records per minute, lets try
sites like Google, Amazon, Yahoo, etc. Ever heard of them?

Dunning-Kruger effect? ;-)

--
Kevin Powick

"Kevin Powick" <kpowick (AT) gmail (DOT) com> wrote

BobJ

On Mar 13, 2:28*am, Kevin Powick <kpow... (AT) gmail (DOT) com> wrote:
I know that one of our clients external web sites would eat that!
Currently investigating SSD's to overcome I/O bottlenecks

In terms of inward facing systems (but still a web application), have
a number a Visage sites (so intranet rather than internet) with >500
(max 1,000) seats, so I think they would be well over this lower limit
to

You guys are just being silly now. Do you really think that Google is
a candidate for this application?

I'm talking about bridging the great leap from flat file to SQL-type
databases, in PHP. Right now PHP programmers only have limited file
support. I'm only talking about giving them an option here. Not
trying to build something that scales into the millions of
transactions.

If we can introduce those non-MV PHP programmers *slowly* to the idea
of multivalue, that would help the entire marketplace, in my opinion.

Then if they want to "improve" their speed by using some "better" mv
database, it won't be a huge jump. It will seem natural.

wjhonson wrote:
This is a good idea, IMO. From where I sit, it would be much more
beneficial to have an ORM layer between Ruby on Rails and the MV
database so that the RoR programmers could access the MV data via
Active Record.

--
frosty