1. DB - Final Question
For my current project, I need a database (Eu or MySQL), front-end (Eu or
?), and web server (Eu or ?). Right now I'm focusing on the database and
front-end. Here are my options:
1. Eu database with Eu front-end
2. MySQL database with Eu front-end
3. MySQL database with xx front-end
Concerns:
a. multi-threads - for multi-user access
b. web serving
c. scalability - for millions of records in multiple databases
d. multi-platform capability - starting w/Linux but client might want a
Windows version in future
One of my thoughts is, I can start with a Eu DB and, when time to scale up,
export the data to a MySQL DB.
Rob Craig, I'd particularly like your input on this, as you know the secrets
of Euphoria capability. I want either assurance or denial that EU can handle
the tasks specified. For instance, how many database requests can a Euphoria
web server take and fulfill per second? (I'll examine on the docs on EDS
after this email, but I'm sure you've done more extensive testing).
Anybody else, please provide your comments! I'm making a final decision and
starting work on this project Sunday (Feb. 11, 2001).
Thanks in advance!
ck
2. Re: DB - Final Question
C. K. Lester writes:
> One of my thoughts is, I can start with a Eu DB and,
> when time to scale up, export the data to a MySQL DB.
That sounds like a reasonable thing to do.
While EDS is a handy tool, it's not in the same league
as full-blown commercial database systems (or serious
database freeware!).
> For instance, how many database requests
> can a Euphoria web server take and fulfill per second?
You'd have to set up your own benchmark.
EDS is pretty fast, and is scalable to millions of records,
but commercial systems will be more robust.
For example if lightning strikes, commercial systems
can guarantee that your database won't be corrupted.
EDS can't do that. Also Euphoria can be run as
separate *processes*, but it doesn't support multiple
threads in one process.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: DB - Final Question
On Fri, 09 Feb 2001, CK wrote:
> For my current project, I need a database (Eu or MySQL), front-end (Eu or
> ?), and web server (Eu or ?). Right now I'm focusing on the database and
> front-end. Here are my options:
>
> 1. Eu database with Eu front-end
> 2. MySQL database with Eu front-end
> 3. MySQL database with xx front-end
>
> Concerns:
> a. multi-threads - for multi-user access
> b. web serving
> c. scalability - for millions of records in multiple databases
> d. multi-platform capability - starting w/Linux but client might want a
> Windows version in future
> Anybody else, please provide your comments! I'm making a final decision and
> starting work on this project Sunday (Feb. 11, 2001).
CK:
When you say "web serving" - do you mean the db will be converted to html
and served over the web in read/only mode? - or does it need to be accessable
as a real, multi-user app with remote client programs reading/writing and
updating the db?
If it's a two way app then you'll need file and record locking. Euphoria
can't do that.
Nor would an Eu server be appropriate. Apache should be able to handle the
load. Euphoria cgi's might suffice for managing the communications between the
web clients and your database. MySQL would probably be a good start, but if
the job is as big as you describe, you'll eventually need to look at Oracle.
Regards,
Irv
4. Re: DB - Final Question
- Posted by Ray Smith <smithr at ix.net.au>
Feb 09, 2001
-
Last edited Feb 10, 2001
Hi,
I haven't followed this thread but if Web development is required
I think you should seriously look at zope (www.zope.org).
It has a built in Web Server/DB Server and a framework for web
development.
Extra modules can be written using Python or download from the
dozens already created.
It's GPL'd and can also connect to pretty much any other web server/DB
server you could think of.
I'm not saying it's the answer but it should definitely be considered.
Ray Smith
----- Original Message -----
From: Irv Mullins <irvm at ellijay.com>
To: EUforum <EUforum at topica.com>
Sent: Saturday, February 10, 2001 1:23 PM
Subject: Re: DB - Final Question
> On Fri, 09 Feb 2001, CK wrote:
>
> > For my current project, I need a database (Eu or MySQL), front-end (Eu
or
> > ?), and web server (Eu or ?). Right now I'm focusing on the database and
> > front-end. Here are my options:
> >
> > 1. Eu database with Eu front-end
> > 2. MySQL database with Eu front-end
> > 3. MySQL database with xx front-end
> >
> > Concerns:
> > a. multi-threads - for multi-user access
> > b. web serving
> > c. scalability - for millions of records in multiple databases
> > d. multi-platform capability - starting w/Linux but client might
want a
> > Windows version in future
> > Anybody else, please provide your comments! I'm making a final decision
and
> > starting work on this project Sunday (Feb. 11, 2001).
>
> CK:
>
> When you say "web serving" - do you mean the db will be converted to html
> and served over the web in read/only mode? - or does it need to be
accessable
> as a real, multi-user app with remote client programs reading/writing and
> updating the db?
>
> If it's a two way app then you'll need file and record locking. Euphoria
> can't do that.
>
> Nor would an Eu server be appropriate. Apache should be able to handle the
> load. Euphoria cgi's might suffice for managing the communications
between the
> web clients and your database. MySQL would probably be a good start, but
if
> the job is as big as you describe, you'll eventually need to look at
Oracle.
>
> Regards,
> Irv
>
>
5. Re: DB - Final Question
On Fri, 09 Feb 2001, CK wrote:
> For my current project, I need a database (Eu or MySQL), front-end (Eu or
> ?), and web server (Eu or ?). Right now I'm focusing on the database and
> front-end. Here are my options:
>
> 1. Eu database with Eu front-end
> 2. MySQL database with Eu front-end
> 3. MySQL database with xx front-end
>
> Concerns:
> a. multi-threads - for multi-user access
> b. web serving
> c. scalability - for millions of records in multiple databases
> d. multi-platform capability - starting w/Linux but client might want a
> Windows version in future
CK:
If you could give more details you could get more definitive answers.
I understand you may be withholding info in order to protect your client
and/or your future income. If so, some of us would be willing to sign
non-disclosure agreements.
On the other hand, perhaps your client is being vague regarding his/her
needs. That can get you into hot water very quickly - you need to have
some serious discussions and draw up some specifications before you get burned.
If you want to discuss this privately, feel free to e-mail me.
That said, given the limited info above, it should be clear that DOS is out
of the question - multi-threading and web serving are not exactly DOS's
strong points :) Why develop a db and front-end on DOS if you won't be
able to use it later?
So, that leaves Linux and Windows. You probably don't want to buy NT server
right now, so I suggest you stick with Linux. If you design your project
right, you may never need to bother with NT at all.
You say you need multi-threads for multi-users, and web serving. Are the users
accessing the db via the web server, or are these two different groups of
people doing different tasks? (Networked users maintaining the db, and others
viewing the data via the web?) Can you meet the UI requirements using nothing
more than standard web browsers and forms, or are there some factors that rule
this out?
Once you thoroughly describe exactly "what" the system is expected to do, the
"how" will likely be obvious.
Regards,
Irv
6. Re: DB - Final Question
- Posted by tone.skoda at SIOL.NET
Feb 10, 2001
>From: Ray Smith <smithr at ix.net.au>
> I haven't followed this thread but if Web development is required
> I think you should seriously look at zope (www.zope.org).
> It has a built in Web Server/DB Server and a framework for web
> development.
> Extra modules can be written using Python or download from the
> dozens already created.
I never understood what Zope was for.
It seems like a lot of complicated stuff for no reason.
I had to do that Zope DTML parser in Visual Basic.
7. Re: DB - Final Question
- Posted by leviathan at uswest.net
Feb 09, 2001
-
Last edited Feb 10, 2001
Heya CK :)
> For my current project, I need a database (Eu or MySQL), front-end (Eu or
> ?), and web server (Eu or ?). Right now I'm focusing on the database and
> front-end. Here are my options:
>
> 1. Eu database with Eu front-end
> 2. MySQL database with Eu front-end
> 3. MySQL database with xx front-end
>
Any of the above works, honestly. Tho it'd take some real skill to use
a Eu db/Eu frontend/Eu server, as you're inventing the wheel for Eu.
IMHO, I work with a MySQL db with Apache+modphp3, so i'm used
to that. But it would be soooo killer to see EDS backend, Eu server,
and Eu communications :) (And it'd put Eu as finally a viable option
for mass database use)
> Concerns:
> a. multi-threads - for multi-user access
How about this: Your program runs as a daemon/TSR, basically,
and the server program shoves to the database software query +
jobnum, and the jobnum would be used on the server-end, which
would keep, perhaps, the IP of the requesting machine or however
web server softwares keep track of clients. This would be done one-
at-a-time, as Eu can't multithread quite yet, but hopefully it'll find the
results fast enough so that the need to multithread isn't so significant.
And this would require you to write your own frontend to your EDS
backend, and your own apache mod too, perhaps. Or your own
webserver software altogether, with just enough functionality for you
to get use out of it :)
> b. web serving
Roll your own. Roll your own...
> c. scalability - for millions of records in multiple databases
EDS can do that, so says Rob :)
> d. multi-platform capability - starting w/Linux but client might want a
> Windows version in future
Shouldn't be too hard, since all you need is cross-platform anyway.
(You're not using ints or anything to go and poke around memory,
its all file commands and stuff)
The only trouble I see? Winsock vs sockets... but perhaps one could
make a unified library for both and use a bunch of "if platform = " to
keep it all together.
> One of my thoughts is, I can start with a Eu DB and, when time to scale up,
> export the data to a MySQL DB.
If EDS can, in fact, scale to millions of records, i see no need to
expand to a sql db...
Hope this helps a little,
--"LEVIATHAN"
8. Re: DB - Final Question
- Posted by Ray Smith <smithr at ix.net.au>
Feb 10, 2001
-
Last edited Feb 11, 2001
----- Original Message -----
From: <tone.skoda at SIOL.NET>
To: EUforum <EUforum at topica.com>
Sent: Sunday, February 11, 2001 12:48 AM
Subject: Re: DB - Final Question
> I never understood what Zope was for.
> It seems like a lot of complicated stuff for no reason.
> I had to do that Zope DTML parser in Visual Basic.
Yes, I agree that it is difficult to explain what Zope is and what it is
good for.
My simple explaination is that it is good for any web development
where you want database access, and particulaly good when you
need multiple level admisitrators (ie. different people looking after
different areas of your web site).
It does take a little while to understand how it all fits together and
works.
Firstly everything (I mean everything) is done using a web browser.
Secondly, it is a "framework" meaning most of the "simple" or "standard"
functions have already been created and you only have to leatn to use them.
But learn using Zope's methods. ie. Data persistance is handled
automatically
and you'll never need to worry about it.
A quote www.zope.org:
"Zope is a framework for building web applications. A web application is a
computer program that users access with a web browser over the Internet. You
can also think of a web application as a dynamic web site that provides not
only static information to users but lets them use dynamic tools to work
with an application."
If you are intersted in web development, particularly dynamic content or
data
driven sites you really need to give Zope a good look.
Ray Smith
