Trying to build a database driven website

[pereges]

Hello, I'm trying to build a database driven website for a library
management system. The database is stored on a remote server which all
of my team mates can access. I've installed MySQL, PHP and Apache on
my machine. I'm a beginner and I really don't understand how to
proceed. My biggest problem is how to connect to the database on
remote mysql server ? Does php allow this kind of thing ? I'm
interested in a web interface on my machine and a database on reote
server. Are there any tutorials/books you would like to recommend ?

[Ivan Marsh]

On Wed, 24 Sep 2008 12:41:20 -0700, pereges wrote:

Hello, I'm trying to build a database driven website for a library
management system. The database is stored on a remote server which all
of my team mates can access. I've installed MySQL, PHP and Apache on
my machine. I'm a beginner and I really don't understand how to
proceed. My biggest problem is how to connect to the database on
remote mysql server ? Does php allow this kind of thing ? I'm
interested in a web interface on my machine and a database on reote
server. Are there any tutorials/books you would like to recommend ?

http://us3.php.net/function.mysql-connect

--
I told you this was going to happen.

[FutureShock]

pereges wrote:

Hello, I'm trying to build a database driven website for a library
management system. The database is stored on a remote server which all
of my team mates can access. I've installed MySQL, PHP and Apache on
my machine. I'm a beginner and I really don't understand how to
proceed. My biggest problem is how to connect to the database on
remote mysql server ? Does php allow this kind of thing ? I'm
interested in a web interface on my machine and a database on reote
server. Are there any tutorials/books you would like to recommend ?

I learned tons of PHP and Database integration using this book:

PHP and MySQL Web development

# ISBN-10: 0672329166
# ISBN-13: 978-0672329166

Scotty

[Rob]

On Sep 24, 8:41*pm, pereges <[e-mail]:

Hello, I'm trying to build a database driven website for a library
management system. The database is stored on a remote server which all
of my team mates can access. I've installed MySQL, PHP and Apache on
my machine. I'm a beginner and I really don't understand how to
proceed. My biggest problem is how to connect to the database on
remote mysql server ? Does php allow this kind of thing ? I'm
interested in a web interface on my machine and a database on reote
server. Are there any tutorials/books you would like to recommend ?

Programming PHP from O'Reilly is probably a good place to start -
http://www.amazon.co.uk/Programming-...dp/0596006810/

Rob.

[doznot]

pereges wrote:

Hello, I'm trying to build a database driven website for a library
management system. The database is stored on a remote server which all
of my team mates can access. I've installed MySQL, PHP and Apache on
my machine. I'm a beginner and I really don't understand how to
proceed. My biggest problem is how to connect to the database on
remote mysql server ? Does php allow this kind of thing ? I'm
interested in a web interface on my machine and a database on reote
server. Are there any tutorials/books you would like to recommend ?

For what little it's worth, about page generation in the general case:

I think database driven websites are fine for large complex sites, but
not so well suited to anything less than large top-dollar installations.

If so (if large and demanding) Drupal is hard to beat. It does have a
bit of a learning curve but it's not all that hard to bring online if
you're content to leave it's native look and feel basically as is. It is
damn difficult to learn how to really tweak it (I tried but gave up on
it, I was just fiddling anyway).

But (for large sites) its page caching is so well done it runs quickly
and reliably with built in search and half a million plugin modules.
So, for sites that warrant, you might be better off learning Drupal than
fighting through building from scratch.

But if you are determined to roll your own, you might want to consider
building around a files-based system. If you use a PHP wrapper that
sucks in files for div contents (rather than behind the scenes mysql
queries) the system runs faster and it's a hell of lot easier to
munge the content.

With a files-based system you can search and replace recursively with
bash perl and sed, without having to fight with complex sql dumps and
updates.

.....I did it with directories. Each page is actually a specially-named
directory containing files that are html fragments, that get sucked in
as div contents, where positioning and appearance are controlled (as
much as possible) by css.

[Jerry Stuckle]

doznot wrote:

pereges wrote:

>Hello, I'm trying to build a database driven website for a library
management system. The database is stored on a remote server which all
of my team mates can access. I've installed MySQL, PHP and Apache on
my machine. I'm a beginner and I really don't understand how to
proceed. My biggest problem is how to connect to the database on
remote mysql server ? Does php allow this kind of thing ? I'm
interested in a web interface on my machine and a database on reote
server. Are there any tutorials/books you would like to recommend ?

For what little it's worth, about page generation in the general case:

I think database driven websites are fine for large complex sites, but
not so well suited to anything less than large top-dollar installations.

I have a lot of database driven sites which are small and definitely not
"top dollar". It's valid for any time you need dynamic content.

If so (if large and demanding) Drupal is hard to beat. It does have a
bit of a learning curve but it's not all that hard to bring online if
you're content to leave it's native look and feel basically as is. It is
damn difficult to learn how to really tweak it (I tried but gave up on
it, I was just fiddling anyway).

There are others which are also good - Joomla, Smarty, etc. Yes, Drupal
can be difficult to configure - but it's much more than just a "database
driven site". It is a full CMS with lots of feature. Something
entirely different.

But (for large sites) its page caching is so well done it runs quickly
and reliably with built in search and half a million plugin modules.
So, for sites that warrant, you might be better off learning Drupal than
fighting through building from scratch.

Actually, I've found it to be just the opposite. I use it and like it -
but for a large site, I would be looking at something else. Drupal
requires a lot of system resources (especially CPU).

But if you are determined to roll your own, you might want to consider
building around a files-based system. If you use a PHP wrapper that
sucks in files for div contents (rather than behind the scenes mysql
queries) the system runs faster and it's a hell of lot easier to
munge the content.

What do you think a file system is - other than a simple type of a database?

With a files-based system you can search and replace recursively with
bash perl and sed, without having to fight with complex sql dumps and
updates.

Even easier to do with a SQL database.

....I did it with directories. Each page is actually a specially-named
directory containing files that are html fragments, that get sucked in
as div contents, where positioning and appearance are controlled (as
much as possible) by css.

Much more complex than using a database. Also prone to file locking
issues, etc. - which a database handles automatically.

Sorry, but it sounds to me like you don't have any real database
experience to base your comments on.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[sheldonlg]

Jerry Stuckle wrote:

doznot wrote:

>I think database driven websites are fine for large complex sites, but
not so well suited to anything less than large top-dollar installations.

I have a lot of database driven sites which are small and definitely not
"top dollar". It's valid for any time you need dynamic content.

Totally agree.

>With a files-based system you can search and replace recursively with
bash perl and sed, without having to fight with complex sql dumps and
updates.

Even easier to do with a SQL database.

MUCH easier to do with a database.

>

>....I did it with directories. Each page is actually a specially-named
directory containing files that are html fragments, that get sucked in
as div contents, where positioning and appearance are controlled (as
much as possible) by css.

Much more complex than using a database. Also prone to file locking
issues, etc. - which a database handles automatically.

Yup.

>
Sorry, but it sounds to me like you don't have any real database
experience to base your comments on.

I fully agree with Jerry on all points here. Using a database for data
driven web sites is the way to go. It is much simpler than handling files.

[doznot]

sheldonlg wrote:

I fully agree with Jerry on all points here. Using a database for data
driven web sites is the way to go. It is much simpler than handling files.

1)
Seems to me file locking is only an issue on update. So if the site is
administered by a single admin, this isn't an issue. If the site
isn't administered by a single admin, then it isn't the "simple" sort
of site I was talking about.

2)
content updates:
So, let's say you have links to other websites scattered over multiple
content blocks in multiple pages (outside the generated navigation
system) and one or more of those links has changed.

These links don't exist as a labeled table column, so you cannot find
them directly with a query. You would have to query all html fragments
in the system with multiple queries, suck those into memory and then right
some code to search and replace the errant link. And then to update
again, and each update would have to be custom written for each
fragment (main display, right column, footer, whatever).
Or you'd have to spend all day using a GUI.

With a files based system I use recursive perl search and replace,
which is so simple do it from the command line, rather than writing
query, search, replace, update code into a use-once file.

......generating pages with PHP doesn't mean maintenance and changes have
to be done that way. Bash perl sed and sometimes awk are too convenient
to throw out the window.

No database experience? I started with Oracle in 1995.
That won't win any contests here, but it represents a lot more
experience than none. I don't want to start a name calling fight.
But I do think there is an important "small site" niche for a files
based system.

[FutureShock]

doznot wrote:

sheldonlg wrote:

>I fully agree with Jerry on all points here. Using a database for
data driven web sites is the way to go. It is much simpler than
handling files.

1)
Seems to me file locking is only an issue on update. So if the site is
administered by a single admin, this isn't an issue. If the site
isn't administered by a single admin, then it isn't the "simple" sort
of site I was talking about.

2)
content updates:
So, let's say you have links to other websites scattered over multiple
content blocks in multiple pages (outside the generated navigation
system) and one or more of those links has changed.

These links don't exist as a labeled table column, so you cannot find
them directly with a query. You would have to query all html fragments
in the system with multiple queries, suck those into memory and then right
some code to search and replace the errant link. And then to update
again, and each update would have to be custom written for each
fragment (main display, right column, footer, whatever).
Or you'd have to spend all day using a GUI.

I am sort of jumping in here to give my opinion and past usage.
It seems to me (from experience) that if you have a Table for all links,
it would be simple enough to use a descriptive label in one field with
the link code in another.

Query the DB, pull in the links table and place it in an array, keys
being the label for each page that requires the links whether it be on a
navbar or separate block.

Then wherever you want to display the link you pull it from the array
that is available throughout the page.

Maybe I am over-simplifying this but it works for me.

Now I have never done file base dynamic sites, so it is hard for me to
compare.

Scotty

>
With a files based system I use recursive perl search and replace,
which is so simple do it from the command line, rather than writing
query, search, replace, update code into a use-once file.

.....generating pages with PHP doesn't mean maintenance and changes have
to be done that way. Bash perl sed and sometimes awk are too convenient
to throw out the window.

No database experience? I started with Oracle in 1995.
That won't win any contests here, but it represents a lot more
experience than none. I don't want to start a name calling fight.
But I do think there is an important "small site" niche for a files
based system.

[doznot]

FutureShock wrote:
REtable for all links.
Links often exist as entries in a named column somewhere,
as part of the navigation system.

But most systems also work with html fragments for the more
variable "display" portions of a page. If a display block
has a link (perhaps and editorial page referring to news stories
out on the net) then that link is not in any directly queryable
column.

And links to newsy items on other sites is a good example. Many
such links do continue to exist for a long time, but they often
get modified by the remote system after a certain period of time.
I often find myself updating links that still exist, that have
been changed by some remotely-located and unknown sys-admin.

.....and if those links are part of text block fragment, which
is common, then query is difficult. Recursive perl over directories
and files is a snap.

[Jerry Stuckle]

doznot wrote:

sheldonlg wrote:

>I fully agree with Jerry on all points here. Using a database for
data driven web sites is the way to go. It is much simpler than
handling files.

1)
Seems to me file locking is only an issue on update. So if the site is
administered by a single admin, this isn't an issue. If the site
isn't administered by a single admin, then it isn't the "simple" sort
of site I was talking about.

I don't know how many times I've heard that argument - and seen it go
down in flames.

2)
content updates:
So, let's say you have links to other websites scattered over multiple
content blocks in multiple pages (outside the generated navigation
system) and one or more of those links has changed.

These links don't exist as a labeled table column, so you cannot find
them directly with a query. You would have to query all html fragments
in the system with multiple queries, suck those into memory and then right
some code to search and replace the errant link. And then to update
again, and each update would have to be custom written for each
fragment (main display, right column, footer, whatever).
Or you'd have to spend all day using a GUI.

With a files based system I use recursive perl search and replace,
which is so simple do it from the command line, rather than writing
query, search, replace, update code into a use-once file.

.....generating pages with PHP doesn't mean maintenance and changes have
to be done that way. Bash perl sed and sometimes awk are too convenient
to throw out the window.

No database experience? I started with Oracle in 1995.
That won't win any contests here, but it represents a lot more
experience than none. I don't want to start a name calling fight.
But I do think there is an important "small site" niche for a files
based system.

Only since 1995? And what have you done with databases on the web - or
even databases in general? It doesn't sound like you've done much at all.

You have made it very obvious you have no idea how a database can be
used effectively for websites. Your own comments betray that.

For one thing - you equate a database with a CMS. They are two entirely
different things.

And the other errors in your statements are just too numerous to even
mention.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

doznot wrote:

FutureShock wrote:
REtable for all links.
Links often exist as entries in a named column somewhere,
as part of the navigation system.

But most systems also work with html fragments for the more
variable "display" portions of a page. If a display block
has a link (perhaps and editorial page referring to news stories
out on the net) then that link is not in any directly queryable
column.

Again, an over-generalized statement based on what you have seen from a
limited number of products (have you really looked at anything other
than Drupal?).

And links to newsy items on other sites is a good example. Many
such links do continue to exist for a long time, but they often
get modified by the remote system after a certain period of time.
I often find myself updating links that still exist, that have
been changed by some remotely-located and unknown sys-admin.

....and if those links are part of text block fragment, which
is common, then query is difficult. Recursive perl over directories
and files is a snap.

It's even easier to update them in a sql database. No perl needed. One
simple SQL UPDATE statement does it all.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[doznot]

Jerry Stuckle wrote:

And the other errors in your statements are just too numerous to even
mention.

OK, we'll try an experiment here. I'll assume a totally subservient
position. I made a terrible mistake by making representations of any
kind. Instead I'll as you, the acknowledged expert, a few questions:

1)
Is it true that many "database driven websites" use text blocks
for storing html fragments, that might, for instance, be used to
fill the contents of a table-td or div? (perhaps not, I'm asking, you
are the expert).

2) if the answer to question 1 is no, then there is no point in
reading further. That would mean I was off base and completely wrong.
But if so, and if those html fragments needed updating, then a query
would have to be written...perhaps a "if table_name.fragment_name like
'%pattern%' ....then use a search and replace mechanism
to replace, and then update. Sure that's possible, but it's a bit
awkward isn't it? compared to two line recursive perl replace?

Please give an example, rather than vague and aggressive assertions.

[Jeff]

doznot wrote:

Jerry Stuckle wrote:

>And the other errors in your statements are just too numerous to even
mention.

OK, we'll try an experiment here. I'll assume a totally subservient
position. I made a terrible mistake by making representations of any
kind. Instead I'll as you, the acknowledged expert, a few questions:

1)
Is it true that many "database driven websites" use text blocks
for storing html fragments, that might, for instance, be used to
fill the contents of a table-td or div? (perhaps not, I'm asking, you
are the expert).

A database is a ubiquitous tool. What I think the OP wants is to
retrieve data about the library and display it. As such you just store
data in the database, you don't format it until you write the page.
Usually this is a complete block of html, a whole table or some such.
What data you bring back will be driven by the sql and generally
formatted one row at a time, but all rows will be formatted using the
same rules.

Now as far as CMS's, usually you are also writing large blocks of
html, not just a bit here and a bit there. And you know exactly where it
is going.

>
2) if the answer to question 1 is no, then there is no point in
reading further. That would mean I was off base and completely wrong.
But if so, and if those html fragments needed updating, then a query
would have to be written...perhaps a "if table_name.fragment_name like
'%pattern%'

Such stuff is usually locked in the template. You should never have
to do a sitewide search and replacement. If you are making sites like
this you have a maintenance nightmare. Don't do that.

Jeff
.....then use a search and replace mechanism

to replace, and then update. Sure that's possible, but it's a bit
awkward isn't it? compared to two line recursive perl replace?

Please give an example, rather than vague and aggressive assertions.

[Jerry Stuckle]

doznot wrote:

Jerry Stuckle wrote:

>And the other errors in your statements are just too numerous to even
mention.

OK, we'll try an experiment here. I'll assume a totally subservient
position. I made a terrible mistake by making representations of any
kind. Instead I'll as you, the acknowledged expert, a few questions:

1)
Is it true that many "database driven websites" use text blocks
for storing html fragments, that might, for instance, be used to
fill the contents of a table-td or div? (perhaps not, I'm asking, you
are the expert).

Not necessarily. It means they use a database to store data of some
kind. It can be anything, from a complete CMS like Drupal to membership
details to shopping cart products - a lot of different things.

2) if the answer to question 1 is no, then there is no point in
reading further. That would mean I was off base and completely wrong.
But if so, and if those html fragments needed updating, then a query
would have to be written...perhaps a "if table_name.fragment_name like
'%pattern%' ....then use a search and replace mechanism
to replace, and then update. Sure that's possible, but it's a bit
awkward isn't it? compared to two line recursive perl replace?

Please give an example, rather than vague and aggressive assertions.

That's because your first premise is 100% incorrect.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[sheldonlg]

doznot wrote:

sheldonlg wrote:

>I fully agree with Jerry on all points here. Using a database for
data driven web sites is the way to go. It is much simpler than
handling files.

No database experience? I started with Oracle in 1995.
That won't win any contests here, but it represents a lot more
experience than none. I don't want to start a name calling fight.
But I do think there is an important "small site" niche for a files
based system.

When I said I agreed with Jerry on all points, I was only referring to
that of using a database being easier. I did not mean to imply (though,
it did) anything about your experience. I apologize for the
mis-statement on my part.

[doznot]

Jerry Stuckle wrote:

>
That's because your first premise is 100% incorrect.

I've been out of town and I don't read news on my traveling laptop.
So I'm jumping back in a bit late.
And this thread is getting a bit tired. However, you (Jerry) have
successfully dodged my main point from the beginning. All I said, at the
start, was that there was a "valid small site niche" for a files-based
CMS (or page generation tool). I never said a files-based system was
"better than" anything. I said it was a valid alternative to a
database, that makes particular sense in the small site context.

The one point that does make (a lot of) sense to me is the inherent
difficulty in performing search and replace operations on html
fragments, that need to be updated. In a database context these
search and replace operations (over semi-random fragments, not
labeled columns) must be framed inside query, fetch, replace and
update sequences in a database. Over files it's so easy you type
the code out at the command line. You cannot do that with query fetch
replace and update sequences, especially when the fragments you are
working over might appear in differently named columns, perhaps even
in different tables.

Html fragments (that exist in all database driven packages I've ever
seen) will contain small sub-strings that periodically need to be
changed. Perhaps it's a link that has been moved, where the link in
question is known to exist on multiple, indeterminate pages.
Or perhaps said html fragments are known to contain references Joe Blow
is now an MD instead of an intern. That particular chore comes up
again and again and again in my work (search for a text pattern
buried in html fragments and change it to something else).

Search and replace over html fragments stored in a database
is more cumbersome than working over files. That makes room for a
niche alternative. A reference to this sort of thing (a files-based
system) was mentioned in this group about a half a year ago and it
got attacked then by the usual aggressive and pretend-to-know-everything
attackers, but it also got praised by at least one of the group's most
prestigious participants.

I don't think a files-based system would be appropriate for a large
commercial site. But for read-mostly informational sites of 100 pages
or less it works well indeed for me, and I find it to be so much
quicker and easier to deal with than the larger database-driven sites,
that I also worked with for years.

[Jerry Stuckle]

doznot wrote:

Jerry Stuckle wrote:

>>
That's because your first premise is 100% incorrect.

I've been out of town and I don't read news on my traveling laptop.
So I'm jumping back in a bit late.
And this thread is getting a bit tired. However, you (Jerry) have
successfully dodged my main point from the beginning. All I said, at the
start, was that there was a "valid small site niche" for a files-based
CMS (or page generation tool). I never said a files-based system was
"better than" anything. I said it was a valid alternative to a
database, that makes particular sense in the small site context.

No, I didn't dodge your main point. I don't think a database-based
system is harder or more complex than a file-based system. Rather, I
think it's much easier. Less to worry about.

The one point that does make (a lot of) sense to me is the inherent
difficulty in performing search and replace operations on html
fragments, that need to be updated. In a database context these
search and replace operations (over semi-random fragments, not
labeled columns) must be framed inside query, fetch, replace and
update sequences in a database. Over files it's so easy you type
the code out at the command line. You cannot do that with query fetch
replace and update sequences, especially when the fragments you are
working over might appear in differently named columns, perhaps even
in different tables.

It is quite easy to do search/replace in a database. Queries are not
hard, and you don't need to fetch anything.

And databases don't require command-line access to the system - not
available on many shared hosts.

Also, if you design your database correctly, they won't appear in
different tables or columns.

Html fragments (that exist in all database driven packages I've ever
seen) will contain small sub-strings that periodically need to be
changed. Perhaps it's a link that has been moved, where the link in
question is known to exist on multiple, indeterminate pages.
Or perhaps said html fragments are known to contain references Joe Blow
is now an MD instead of an intern. That particular chore comes up
again and again and again in my work (search for a text pattern
buried in html fragments and change it to something else).

Quite easy to do in a database, if you know how. In fact, even easier,
if you plan your database with changing data in mind.

In the case of a link, for instance - just have a table with links in it
and refer to it from other tables. That way you only need to change one
link.

However, even if you have the link embedded in multiple html fragments,
it's quite easy to change.

Search and replace over html fragments stored in a database
is more cumbersome than working over files. That makes room for a
niche alternative. A reference to this sort of thing (a files-based
system) was mentioned in this group about a half a year ago and it
got attacked then by the usual aggressive and pretend-to-know-everything
attackers, but it also got praised by at least one of the group's most
prestigious participants.

Not if you know how do to it, it isn't.

I don't think a files-based system would be appropriate for a large
commercial site. But for read-mostly informational sites of 100 pages
or less it works well indeed for me, and I find it to be so much
quicker and easier to deal with than the larger database-driven sites,
that I also worked with for years.

I'm glad it works well for you. But I doubt it will work for most sites
- or on many shared hosting companies (which don't have command line
access).

A database-based solution works on any host which supports databases
(and if they don't, they aren't worth using, IMHO).

But you ignored my main point. A vast majority of the database-driven
sites do NOT store such HTML in databases. The main ones which do are
using CMS's such as Drupal, Joomla, Mambo, etc. That's a completely
different approach to database-driven websites.

I've only had one site (a non-profit) which used a CMS, and that's
because they needed a blog. And actually, the blog was only a small
part of the site. The rest of the site was also database-driven - but
had no HTML (other than that entered by members for their own pages).
However, it used databases heavily.

All the rest of my sites use databases heavily, also. But they aren't a
CMS, so they have very little HTML in the database.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[doznot]

Jerry Stuckle wrote:

All the rest of my sites use databases heavily, also. But they aren't a
CMS, so they have very little HTML in the database.

Finally--after all this time--an answer with specific argument, rather
than unsupported insult. Good work Jerry. You're coming around.

OK, it appears we have a semantic hair to split.
Database-driven sites don'tstore HTML fragments, only CMSs do.
In a database-driven site, by your definition, every string and every
tag from every page is stored in a table.column so it can be directly
updated by sql.

*If* such a system existed, I accept your argument, for that system
and all others like it.

I'm signing off this thread permanently, regardless response.

[Jerry Stuckle]

doznot wrote:

Jerry Stuckle wrote:

>All the rest of my sites use databases heavily, also. But they aren't
a CMS, so they have very little HTML in the database.

Finally--after all this time--an answer with specific argument, rather
than unsupported insult. Good work Jerry. You're coming around.

I guess you can't read. I had specific arguments above.

OK, it appears we have a semantic hair to split.
Database-driven sites don'tstore HTML fragments, only CMSs do.
In a database-driven site, by your definition, every string and every
tag from every page is stored in a table.column so it can be directly
updated by sql.

I never said that.

*If* such a system existed, I accept your argument, for that system
and all others like it.

I'm signing off this thread permanently, regardless response.

That's good - because you have no idea what you're talking about.

You claim you've been using Oracle since 1995 - but you show absolutely
zero understanding of databases and how they are used.

More likely you used an application which accessed an Oracle database
and never have done any database programming.

I suggest you read up on how databases are used in the real world and
come back when you can discuss this intelligently.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

doznot wrote:

Jerry Stuckle wrote:

>All the rest of my sites use databases heavily, also. But they aren't
a CMS, so they have very little HTML in the database.

Finally--after all this time--an answer with specific argument, rather
than unsupported insult. Good work Jerry. You're coming around.

I guess you can't read. I had specific arguments above.

OK, it appears we have a semantic hair to split.
Database-driven sites don'tstore HTML fragments, only CMSs do.
In a database-driven site, by your definition, every string and every
tag from every page is stored in a table.column so it can be directly
updated by sql.

I never said that.

*If* such a system existed, I accept your argument, for that system
and all others like it.

I'm signing off this thread permanently, regardless response.

That's good - because you have no idea what you're talking about.

You claim you've been using Oracle since 1995 - but you show absolutely
zero understanding of databases and how they are used.

More likely you used an application which accessed an Oracle database
and never have done any database programming.

I suggest you read up on how databases are used in the real world and
come back when you can discuss this intelligently.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Richard]

So ...
who has the biggest dick?

R.

[Jerry Stuckle]

Richard wrote:

So ...
who has the biggest dick?

R.

Who ask you, troll?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Richard]

You lose.

:)

R.

[doznot]

I am signing off this thread this time.
But as final thought (from me anyway) it would be a real pleasure,
here in this group, if it somehow became possible to venture an
opinion--about almost anything--without the almost certain expectation
of insult-filled response.

Opinions can and should be debated honestly and respectfully.
That's the essence of critical thinking: you try to understand both
sides of any argument. You respect both sides. You compare arguments and
do your best to support your idea with logical argument, rather than
aggressive, condescending insult.

This could be a great group. There many skilled and knowledgeable
hackers who participate here. But, from what I see, although questions
do get answered, assertion and opinion almost *always* gets attacked
with derisive and largely unsupported insult. It would be a real
pleasure here if that changed.

[Jerry Stuckle]

doznot wrote:

>
I am signing off this thread this time.
But as final thought (from me anyway) it would be a real pleasure,
here in this group, if it somehow became possible to venture an
opinion--about almost anything--without the almost certain expectation
of insult-filled response.

Opinions can and should be debated honestly and respectfully.
That's the essence of critical thinking: you try to understand both
sides of any argument. You respect both sides. You compare arguments and
do your best to support your idea with logical argument, rather than
aggressive, condescending insult.

This could be a great group. There many skilled and knowledgeable
hackers who participate here. But, from what I see, although questions
do get answered, assertion and opinion almost *always* gets attacked
with derisive and largely unsupported insult. It would be a real
pleasure here if that changed.

Read back. I did exactly that. But then you ignored some things and
took other things out of context. You even misquoted me. The thread
proves every bit of it.

If you want to carry on an intelligent discussion, then do so, if you can.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================