At what point is a database necessary?

How many products?

[starlygirl]

I'm selling about 60 products right now (each available in different sizes). My site is done in straight html. I can see where a database shopping cart might be nice, but also see some disadvantages.

How many products do you feel is too many to keep using an html site? At what point does it make sense to switch to a php site with inventory control?

[sun818]

My site is static and I have over 1,000 live products. I publish static pages from a database. You could just as easily use PHP with mod_rewrite to make your PHP pages look like static pages and get the best of both worlds. I think a database is necessary once you feel you can't keep track of all your products in your head.

[topr8]

>> At what point does it make sense to switch to a php site with inventory control?

when it becomes too much work not to?

if it is manageable right now then whats the problem.

reasons to change: automaticlly show items out of stock when sold out, change prices with ease

if your stock is constant with little change and you don't want a cart then there is no need to change.

... although once i first went database driven and began to track users through my site, the new insight i gained blew my mind

[shri]

You also have to consider customer information, order management, shipping calculation, invoicing.. in addition to just products.

If you have the option, look at a database driven package to begin with. Demo / eval it and then work out the benefits / pros and cons.

I'm a big fan of oscommerce derivatives for startup operations.

[derekwong28]

We switched a couple of years ago and never looked back. I would recommend a cart that can generate a static catalog which will index better in search engines. If you want to keep your present static html pages, you can use something like litecommerce which will give you the best of both worlds.

[Morgenhund]

> a static catalog which will index better in search engines.

A properly written php is indexed just as well. Actually, php can be completely masquaraded as html, like this:
1. www....com/index.php?a=b&d=e&x=y -- not good?
2. www....com/index/b/e/y.html -- wery well then! (hovewer, written in pure PHP!)

SEO is a huge topic, look for corresponding forums here.

[chodges84]

Morgenhund,

I'm just changing over from a static site to a database driven one. My new URL's will look like the one in your example. Will this cause a problem with search engines, or can I change them to look like the second one in your example?

[lorax]

>> when it becomes too much work not to?

I totally agree. Take advantage of the benefits of static pages for as long as you can.

>> Will this cause a problem with search engines, or can I change them to look like the second one in your example?

Many folks (including me) believe you will be somewhat penalized (or at least less successful) in the SERPs if you pass variables on the URL. You can make them look like static paths/files by using Apache's mod rewrite.

See:
[webmasterworld.com...]
[webmasterworld.com...]
[webmasterworld.com...]
[webmasterworld.com...]
[webmasterworld.com...]

[Morgenhund]

There is a tehnique other than mod_rewrite.

Actually, you can name your index.php as 'index' (without extension), but tell Apache this is an executable PHP script.

<Files ~ "^(index¦products¦categories)$">
ForceType application/x-httpd-php
</Files>

Then, looking for .com/index/blah/blah/blah.html, the PHP script `index´ will receive `/blah/blah/blah.html´ in $PATH_INFO variable. You just parse this then into corresponding variables.

I re-hacked my osCommerce catalogue and products pages in this way (did not know about mod_rewrite :-)

Actually, it seems at least big G. has nothing against?a=b&x=y varaibles (does not mean will always be so).

What is more important -- not to have same pages be accessible through different URLs (and have these different URLs accessible on your pages).

If same page is shown under /x/yyy/1.html and /x/y/1.html (possible one page is not a harm, but with certain amount),
you will found yourself at the page 65535 in G. search results...

[chodges84]

I already find myself that far down on G anyway, although things did actually improve after the Jagger update.

I'll look into both options. I was going to 301 all the existing URL's to their new database equivalent. Will that avoid duplication penalties?

[Morgenhund]

chodges84:

301 worked fine for me -- and saved me after Bourbon update.

I always do 301 if something has changed with my URLs.

It seem very unappropriate -- to find somebody's product page through search engine and get 404 or "wrong parameters" :)

In May, I've lost 50% of sales because my payment gateway provider (a major local bank) changed payment processing URL and neither informed anybody nor set "moved permanently". I've noticed it too late :(

[sharbel]

I cant imagine running any e-commerce site without some form of datastore. Even the piddly 'test' e-commerce sites I develop to see if a product takes off is always tied to a database. It's not so much for the product management, its more for cart/order management, as well as all the tracking modules that I developed.

I guess if you are using a third-party solution hosted on the providers server, I guess it would be different though..

[surfin2u]

Databases in shared hosting situations can be unreliable, so unless you have a dedicated database server, or some other way of insuring that your database is always available, it may not be a good idea to risk losing sales if a database is down. If you use the database to publish static pages then you've eliminated the risk, since only the admin will notice a database failure, not a customer.

[sharbel]

Change your host if your shared enviornment database is unreliable..

[derekwong28]

I wonder is there a size limit for mysql database after which it becomes slow and unreliable? Ours is 70M at the moment.

[shri]

Derek,

We have databases that go upto 10GB... no problems. Needless to say, you do need to scale the processors and memory up and get help with indexing and queries to make sure they're well optimized.

Sort of getting back on topic...

The advantages I see of a database driven approach is you're seperating your data (raw products) from your "business logic" (inventory rules, shipping rules etc) and your "presentation" (html).

Anyone who is interested in a long term approach to their ventures MUST look at how they can use their data in a variety of ways (importing to excel for year end taxes... figuring out what people have purchased and using that data in newsletters, instant recommendations etc).

You can even use this data to create static pages if you want them for search engine spidering (more on this topic when I get some time.. there are a few concepts presented in this thread that I'd like to explore a bit more over the next few weeks).

A database can be anything from a text files which are manipulated by PHP / Perl to a higher end database like Oracle.

Don't worry about shared environments or dedicated servers or the size of the data for new and modest ventures. Those are eventually good problems to solve, if your architecture is setup correctly.

[lorax]

There is a tehnique other than mod_rewrite.

Actually, you can name your index.php as 'index' (without extension), but tell Apache this is an executable PHP script.

<Files ~ "^(index¦products¦categories)$">
ForceType application/x-httpd-php
</Files>

Then, looking for .com/index/blah/blah/blah.html, the PHP script `index´ will receive `/blah/blah/blah.html´ in $PATH_INFO variable. You just parse this then into corresponding variables.

I hadn't thought of this approach but it makes sense. Have you done any benchmarking or have insight to share on the performance differences between the two techniques?

[webtress]

Database driven websites! Don't leave home without it

[surfin2u]

Change your host if your shared enviornment database is unreliable.

If you are in a shared environment, then it's always possible for people, who you're sharing the database server with, to overwhelm the server. It's just a question of being lucky or unlucky. I've had months go by with no problems, and then had 10 connect failures a day for a while. I've used many hosting outfits and each one has its issues.

I've modified my site so that the database is only used during administrative procedures. All the data in the database is published to static pages, so users experience no impact if the database is down. Other than a dedicated server, this seems like the best solution that I can come up with.

[chodges84]

going back to the mod_rewrite etc.

Currently my pages are in the form www.domain.com/catalogue/blue_widgets.html

with the new database backend it will now say something like this

www.domain.com/index.php?area=category&ui=6

Is it possible to get this into a nice static file.

I also have a section where you can search by make and model, which would read

www.domain.com/index.php?area=manufacturer&ui=3
could that be changed to www.domain.com/ford/

If so, could someone point me in the direction of how to do it. Or does it not really help me that much, and I'd be aswell off sticking with the URL's it will create?

Thanks.

[sun818]

Change ui=3 to the actual category title instead of the record ID. Then you can use mod_rewrite to replace the ui= with a forward slash.

[Morgenhund]

Have you done any benchmarking or have insight to share on the performance differences between the two techniques?

lorax:
Actually, no. Although, since biggest performance eaters usually are disk input/output operations, I suppose performance difference should not be remarkable.

URLs are:
www.domain.com/categories/blue_widgets/101.html
www.domain.com/products/big_blue_widget/12.html

In standard header include file:
$PARAMS_SEQ = array();
$PARAMS_SEQ['categories'] = array('seo_param', 'category_code');
$PARAMS_SEQ['products'] = array('seo_param', 'item_code');

Then I just '/' - parse these ordered params from $PATH_INFO and store to $HTTP_GET_VARS,
accordingly to current file name ('products' or 'categories'):
$HTTP_GET_VARS['category_code'] = 101; // .html is just brutally removed
'seo_param' is just search engines teaser and is not being used in scripts.

And then I just happily use $HTTP_GET_VARS in 'categories' or 'products' thereafter. If situation changes, and URLs like?a=b&c=d will be more favorable than /a/b/c, I can just remove this
processing part and use plain $HTTP_GET_VARS.

What appelas me in this technique, it is its portability.
You just leave most of pretty critical processing inside your scripts rather than some external .htaccess files.
I just trust my scripts more, than mod_rewrite, but it is only my arrogant habit :)

chodges84:
Since search engines never post forms, you can omit optimizing URLs for search forms,
and just use URLs in any form.

However, if you want external links to your search results, there are several techniques:

1. www.domain.com/searches/keyword
'searches' is a script that processes 'keyword' from $PATH_INFO or through mod_rewrite (not sure about mod_rewrite -- never used it)

2. www.domain.com/searches/keyword.html
same as above, but script just removes trailing .html and treats remainder as a keyword

3. Probably, you cannot [or should not] use www.domain.com/keyword directly (without a clearly defined script to process it), to avoid messy problems in the futire.