I'm looking for a application, and or ideas on how to ....
Set up a web page that can be cataloged by search engines capturing all of the part numbers in a db. This page would be tied to a MySql or other Linux DB so that people can also do a basic on site part number search.. We have 150,000 different part numbers, we would like all 150,000 picked up by the different search engines.
Can anyone come up with any ideas??
The platform is a basic P4 running Centos 5, disk space isn't much of an issue, I have 100 gig available for the application. The only other application on the machine is a picture server for off site auctions, so CPU load isn't major factor.
Thanks, john
Am 26.11.2008 um 01:34 schrieb John Plemons:
I'm looking for a application, and or ideas on how to ....
Set up a web page that can be cataloged by search engines capturing all of the part numbers in a db. This page would be tied to a MySql or other Linux DB so that people can also do a basic on site part number search.. We have 150,000 different part numbers, we would like all 150,000 picked up by the different search engines.
Can anyone come up with any ideas??
The platform is a basic P4 running Centos 5, disk space isn't much of an issue, I have 100 gig available for the application. The only other application on the machine is a picture server for off site auctions, so CPU load isn't major factor.
Why the hassle?
Regards, Rainer
Thanks for the feedback, but not exactly what I have in mind, the inventory is fluid and quantity changes are updated daily. My goal would be a real time link to a secondary DB which has a update push from the primary DB, the primary is a Firebird DB under Windows 2003 server..
john
Rainer Duffner wrote:
Am 26.11.2008 um 01:34 schrieb John Plemons:
I'm looking for a application, and or ideas on how to ....
Set up a web page that can be cataloged by search engines capturing all of the part numbers in a db. This page would be tied to a MySql or other Linux DB so that people can also do a basic on site part number search.. We have 150,000 different part numbers, we would like all 150,000 picked up by the different search engines.
Can anyone come up with any ideas??
The platform is a basic P4 running Centos 5, disk space isn't much of an issue, I have 100 gig available for the application. The only other application on the machine is a picture server for off site auctions, so CPU load isn't major factor.
Why the hassle?
Regards, Rainer _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.9.10/1810 - Release Date: 11/24/2008 2:36 PM
On Tue, 25 Nov 2008 22:28:50 -0500 John Plemons john@mavin.com wrote:
Thanks for the feedback, but not exactly what I have in mind, the inventory is fluid and quantity changes are updated daily. My goal would be a real time link to a secondary DB which has a update push from the primary DB, the primary is a Firebird DB under Windows 2003 server..
I don't think you're going to get the results that you think you're going to get, assuming that by "search engines" you mean Google, MSN and the like. Your site may or many not be spidered by the search engines on a daily, weekly or monthly basis. "Google works in mysterious ways."
I get the impression that you want someone who searches one of the search engines for Widget No. 12345 to be sent to your site if you happen to have Widget No. 12345 in stock today. You're planning to use Google as your database frontend and salesman, in other words. Nothing wrong with that in theory, I suppose, but I really don't think you're going to be able to keep an up-to-the-minute inventory on Google unless you pay them for the service in some way.
Frank thank you for the feedback... I understand that there will not be a real time Spidering and update of Google, that's fine, once the 150,000 part numbers are Spidered once, then that is 1/2 the work done. The other side, that I want to be some what real time, is a onsite search feature so that real customers can see true, or close to true information... What some people do, is build a pade with every part number know to man on it, just a basic stream of text on a page, one after an other, after several tens if not hundreds of pages they have the information on the web. In that manner, they then can be Spidered by the search engines. These companies don't have the product, but they do get requests for the product and then they go out into the world to fine it, they are known as brokers. The other side of the coin is what we do, we hold inventory on at least 150,000 different part numbers, in a mix of quantities amounting to millions of pieces of inventory on hand. I have this inventory in a Firebird DB, I'd like to find a way of dumping this information into a program that will create pages on our website, or at least create a catalog on our website that can be spidered by the various search engines. My first thought was a basic Shopping Cart, I use one now on our surplus electronics and consumer website.. Some basic information on the part, entered in plain text, and the cart uses its PHP scripting to generate a page, these pages are captured by the search engine spiders, driving people to our website. It is called SquirrelCart, but it has more bells an whistles than is needed for this project, if a person gets to our site, I just want them to be able to see if we have the item in stock and show them a quantity, if we do, then give them a phone number to yalk with my sales department, or a web form to let them contact us... KISS, I want to keep it simple...
John http://www.mavin.com
Frank Cox wrote:
On Tue, 25 Nov 2008 22:28:50 -0500 John Plemons john@mavin.com wrote:
Thanks for the feedback, but not exactly what I have in mind, the inventory is fluid and quantity changes are updated daily. My goal would be a real time link to a secondary DB which has a update push from the primary DB, the primary is a Firebird DB under Windows 2003 server..
I don't think you're going to get the results that you think you're going to get, assuming that by "search engines" you mean Google, MSN and the like. Your site may or many not be spidered by the search engines on a daily, weekly or monthly basis. "Google works in mysterious ways."
I get the impression that you want someone who searches one of the search engines for Widget No. 12345 to be sent to your site if you happen to have Widget No. 12345 in stock today. You're planning to use Google as your database frontend and salesman, in other words. Nothing wrong with that in theory, I suppose, but I really don't think you're going to be able to keep an up-to-the-minute inventory on Google unless you pay them for the service in some way.
No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.9.10/1810 - Release Date: 11/24/2008 2:36 PM
John Plemons wrote:
Frank thank you for the feedback... I understand that there will not be a real time Spidering and update of Google, that's fine, once the 150,000 part numbers are Spidered once, then that is 1/2 the work done. The other side, that I want to be some what real time, is a onsite search feature so that real customers can see true, or close to true information... What some people do, is build a pade with every part number know to man on it, just a basic stream of text on a page, one after an other, after several tens if not hundreds of pages they have the information on the web.
a web catalog should NOT be creating static page files for each catalog item in the database, it should be a browsable dynamic HTML thing, thats generating the pages on the fly based on database queries. to the user, both implementations would look approximately the same. if you want your catalog 'spiderable', then it should have hierarchical navigation that will get you to every item (category, subcategory, item, next, last, etc), also hide the ?q=xxxxx&pn=xxxx stuff via URL redirection so the web pages appear as http://yourcatalog/toplevelcategory/category/subcategory/part/option or whatever.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Frank Cox Sent: Wednesday, November 26, 2008 12:01 AM To: CentOS mailing list Subject: Re: [CentOS] Looking for an application to work with Centos
On Tue, 25 Nov 2008 22:28:50 -0500 John Plemons john@mavin.com wrote:
Thanks for the feedback, but not exactly what I have in mind, the inventory is fluid and quantity changes are updated daily. My goal would be a real time link to a secondary DB which has a
update push from
the primary DB, the primary is a Firebird DB under Windows
2003 server..
I don't think you're going to get the results that you think you're going to get, assuming that by "search engines" you mean Google, MSN and the like. Your site may or many not be spidered by the search engines on a daily, weekly or monthly basis. "Google works in mysterious ways."
True google works in mysterious ways but,,, I hate to say this but this can be done VIA the Google Search Appliance and it is native to Linux also!!
JohnStanley
I get the impression that you want someone who searches one of the search engines for Widget No. 12345 to be sent to your site if you happen to have Widget No. 12345 in stock today. You're planning to use Google as your database frontend and salesman, in other words. Nothing wrong with that in theory, I suppose, but I really don't think you're going to be able to keep an up-to-the-minute inventory on Google unless you pay them for the service in some way.
John Plemons schrieb:
Thanks for the feedback, but not exactly what I have in mind, the inventory is fluid and quantity changes are updated daily. My goal would be a real time link to a secondary DB which has a update push from the primary DB, the primary is a Firebird DB under Windows 2003 server..
From a (very) brief look at the google-site, I gather that there is an
API where you can push data into Google-Base.
Google-Base is really the only way to get mass-data into Google. Do you think Google spiders ebay? Do you think they are going to spider your "site"?
You have to write an adapter that communicates changes in your DB to Google-Base, using the XML-RPC API that they provide.
Regards, Rainer
John Plemons wrote:
Thanks for the feedback, but not exactly what I have in mind, the inventory is fluid and quantity changes are updated daily. My goal would be a real time link to a secondary DB which has a update push from the primary DB, the primary is a Firebird DB under Windows 2003 server..
150,000 entries is not a big number for databases - you should be able to hook perl DBI connections to both databases and pull updates at some reasonable interval. I'd search on freashmeat.net for a 'shopping cart' application to display the catalog and try to find one where the db entries are easy to match up with what you already have.
John Plemons wrote:
Set up a web page that can be cataloged by search engines capturing all of the part numbers in a db. This page would be tied to a MySql or other Linux DB so that people can also do a basic on site part number search.. We have 150,000 different part numbers, we would like all 150,000 picked up by the different search engines.
John Thomas wrote:
John Plemons wrote:
Set up a web page that can be cataloged by search engines capturing all of the part numbers in a db. This page would be tied to a MySql or other Linux DB so that people can also do a basic on site part number search.. We have 150,000 different part numbers, we would like all 150,000 picked up by the different search engines.
Erm, yes. Good answer (maybe) but you seem to have hit reply on the wrong question.
Ralph
Ralph Angenendt wrote:
John Thomas wrote:
John Plemons wrote:
Set up a web page that can be cataloged by search engines capturing all of the part numbers in a db. This page would be tied to a MySql or other Linux DB so that people can also do a basic on site part number search.. We have 150,000 different part numbers, we would like all 150,000 picked up by the different search engines.
Erm, yes. Good answer (maybe) but you seem to have hit reply on the wrong question.
Ouch!
It brings to mind the saying, that I will probably mess up, "If you learn to use a hammer, everything becomes a nail." I have learned to use Drupal and thought it was a good solution to consider. Perhaps I need to take a screwdriver course to broaden my base.
On Tue, Nov 25, 2008 at 7:34 PM, John Plemons john@mavin.com wrote:
I'm looking for a application, and or ideas on how to ....
Set up a web page that can be cataloged by search engines capturing all of the part numbers in a db. This page would be tied to a MySql or other Linux DB so that people can also do a basic on site part number search.. We have 150,000 different part numbers, we would like all 150,000 picked up by the different search engines.
One thing I suggest you do, regardless of what technology you end up with, is have a Sitemap for Google and a Sitemap for Yahoo on your web site. Google has Webmaster Tools and you can register the site with them and their Search Engines will visit your site.
-
Frank Cox -
John -
John Plemons -
John R Pierce -
John Thomas -
Lanny Marcus -
Les Mikesell -
Rainer Duffner -
Ralph Angenendt