I'm just wondering about the speed of SQL.. I am wondering cause I would like to keep my site as small as possible.. in order to do this.. I must not use many html BUILT pages.. and must keep the database to MySQL itself..

I plan to have my whole entire site running off of .cgi files in order to save space.. although this may take much bandwidth.. i don't really care.. cause bandwidth is getting cheaper with better network connections..

so.. if i were to build my whole site off cgi files with them querying the sql database.. would it still handle MANY items?

would there even be a change in speed? (of course there will.. but i mean a huge difference)

alex's multi template index.cgi seems to be able to handle it..

anyways.. ever since i started using SQL.. flat file is a thing of the past

btw.. i have review.cgi in MySQL.. most likely it will work with Links SQL.. cause it's almost all stand alone except for like 1 part.. the LinkID..

jerry

I think you are looking at it wrong.

I agree that for most real-world applications, affordable (free) SQL servers have made flat-file management systems a thing of the past, the way dBaseII did on the PC waaaaay back.

Anything you put into a MySQL database is going to have a larger footprint than the same amount of stuff in static HTML. Bandwidth is _not_ the problem, that's the same no matter how the page is generated -- CPU is the big issue.

With static pages, you burn CPU _once_

With dynamic pages, you burn CPU with every access.

That's why the build-changed is such a requested feature. Only data that changes is re-built. No CPU is wasted on unnecessary re-builds.

The more CGI processes a machine runs, the slower it becomes. So, that's why static pages are the way to go for data that doesn't change. If you have a fast machine, and you are the only one on it, and you get 100 hits an hour, it will be blindingly fast. If you share a machine, and you get 10 hits a second, you'll probably die.

BTW -- how do you return a list of field names in a table in perl? SHOW FIELDS FROM "table" works from the command line, but I can't figure out what type of datatype it returns to make the names available to PERL.

Pugdog is absolutely correct. One cannot ignore cpu load especially if you are virtually hosted. I run on dedicated but I still have to be cognizant of cpu resources. I dumped quite of few scripts to increase server speed. My sites are extremely CGI-intensive and the result was a dramatic improvement in server performance and page loading.

Afterall, the rate determining step will always be the slowest step and if your server is bogged down with CGI, then no matter how fast your Internet connection is, your site will be slow as molasses in winter - and I know from living in Canada... brrr

Dan

Hello widgetz!


I would appriciate to know from you where do I find it. Thanks


------------------
rajani

pugdog..

i see your point.. i guess i will go into building html pages too (build changed that is)..

i guess i will have to "invest" in a higher package for webhosting then.. right now i'm at a 35mb storage/2500mb bandwidth.. which is pretty small.. i have paid six months in advance (ending.. in march).. so at that time.. i will upgrade.. [i don't think i am launching site until summer.. so i got a long ways to go..]

but that's what you get.. for being a high school student! NO FREE TIME..

jerry

rajani.. i don't even use Links SQL.. I saw it in one of the posts..

pugdog.. you know that book by oreilly on msql and mysql.. for some reason it was shipped to my doorstep today..

i don't know why.. i didn't buy it.. came from amazon.com directly to me via UPS.. also came with another oreilly called "writing apache modules with perl and c"..

guessing someone bought it for me.. too much of a coincidence..

btw.. to get fields you do this:

my $names = $sth->{NAME};

and $names is a referenced array of the field names..

so

@$names would equal something like ('id', 'title'........);

this of course is done after an execute.. and it only returns the fields you queried for..

jerry

Congrats on the books They are pretty good ones. The MySQL/mSQL has _loads_ of typos, I was going to report them, but figured after about 30 it was too depressing <G>... but the reference is really good, and the differences as to what it can and can't do makes it worth it. Between it and the on-line docs _almost_ everything is answered.

For some reason I can't seem to return the names, must be something obscure in my code (I'm using default variables for the first time in many, many moons, and I might be changing something inadvertantly).

Thanks.

Still having problems with the values returned. $sth->{NAME} isn't returning what I'm expecting it to return -- it's giving me "field, type, not null, etc"

I can't seem to get into the "Field" column to get the list of actual field names. The "Show COLUMNS FROM $table" works, but I can't seem to access the returned data.

This is driving me buggy.

i always do it the way i showed you.. perhaps you are not using it in the right place..

show some code.. what i'm thinking is that you didn't put it after the execute thing.. or you are using a different handler other than $sth..

jerry

No, it's in the right place... I'm just not sure what it's pointing to.

I can see what it's doing, but not why it's doing it.

This is based on the examped in the middle of the mysql book, I wanted a database walker for reference.


I stripped the code a bit, but the output it gives is:


Rather than the list of the field names in the table. I can't seem to get the "Field" into any sort of structure, or even traverse it using an array.

Hi Pugdog,

Your query was:

SHOW COLUMNS FROM $_

So, what you get back is:

Field: ID
Type: Char
Null: YES
Key:
Default: 0
Extra:

For example. So $sth->{NAME} is returning the right thing. In this case, you just want to do:

while ($field = $sth->fetchrow_hashref) {
print "Column: ", $field->{Field}, "<br>";
}

and it will print them out. To use $sth->{Name} the way you are thinking, do:

$sth = $dbh->prepare ("SELECT * FROM Table");
$sth->execute();
$names = $sth->{NAME};

and it will have a list of all field names.

Cheers,

Alex

Thanks!

I knew I was pointing to the wrong stuff

I was trying to avoid the "select * from table" since some of the tables could be pretty huge, and there _had_ to be a way to just get the field names.

I had tried the $field->{Field} thing (I think) before, but it works now

If anyone's interested it's a silly little piece of cgi code, but it can give a list of what databases exist, what tables are in each database, and what fields are in what tables, which if your site gets big and ugly can help find things.


[This message has been edited by pugdog (edited October 07, 1999).]