Обсуждение: RFC: Product directory
I'm looking at replacing the ad-hoc lists of products at http://www.postgresql.org/download/ and http://www.postgresql.org/download/commercial with a product directory. I'd like to keep it fairly simple, and propose the following data be stored: id serial primary key -- easier in the framework, complaints to /dev/null publisher text -- Company/person/project name publisher_url text -- Company/person/project URL product text -- Product name product_url text -- URL for the product category int4 -- Category ID (fkey -> categories table) description text -- Product description price text -- Pricing info (where relevant) licence char(1) -- Licence type flag The categories table would simply be a lookup table of category names: Administration/development tools Programming interfaces Clustering/replication Procedural languages Reporting tools PostgreSQL extensions Applications ?? The licence type codes will be hardcoded: 'o' - Open Source 'c' - Commercial 'f' - Freeware Sound reasonable? Anything I've missed? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Mon, Jun 02, 2008 at 09:30:58AM +0100, Dave Page wrote: > I'm looking at replacing the ad-hoc lists of products at > http://www.postgresql.org/download/ and > http://www.postgresql.org/download/commercial with a product > directory. I'd like to keep it fairly simple, and propose the > following data be stored: > > id serial primary key -- easier in the framework, complaints to /dev/null > publisher text -- Company/person/project name > publisher_url text -- Company/person/project URL > product text -- Product name > product_url text -- URL for the product > category int4 -- Category ID (fkey -> categories table) > description text -- Product description > price text -- Pricing info (where relevant) Price is too complicated to model, and suffers from "cache coherency" issues. Pointing to a web site, where appropriate, would handle this better. > licence char(1) -- Licence type flag CREATE TABLE category ( category_id SERIAL PRIMARY KEY, category_name TEXT NOT NULL ); CREATE UNIQUE INDEX unique_category_idx ON category(trim(lower(category_name))); CREATE TABLE license ( license_id SERIAL PRIMARY KEY, license_name TEXT NOT NULL, license_text TEXT NOT NULL ); CREATE UNIQUE INDEX unique_license_idx ON license(trim(lower(license_name))); CREATE TABLE product ( product_id SERIAL PRIMARY KEY, product_name TEXT, product_url TEXT, publisher TEXT, publisher_urlTEXT, description TEXT ); CREATE TABLE product_category ( product_id INTEGER NOT NULL REFERENCES product(product_id), category_id INTEGER NOT NULLREFERENCES category(category_id), ); CREATE TABLE product_license ( product_id INTEGER NOT NULL REFERENCES product(product_id), license_id INTEGER NOT NULLREFERENCES license(license_id), ); CREATE VIEW product_overall AS SELECT p.product_name, p.publisher, p.publisher_url, p.product_url, p.description, array_accum(l.category_name) AS "Category(s)", array_accum(l.license_name)AS "License(s)" FROM product p LEFT JOIN product_category pc ON (p.product_id= pc.product_id) RIGHT JOIN category c ON (pc.category_id = c.category_id) LEFT JOIN product_licensepl ON (p.product_id = pl.license_id) RIGHT JOIN license l ON (pl.license_id = l.license_id) GROUP BY p.product_id, p.publisher, p.publisher_url, p.product, p.product_url, p.description; > The categories table would simply be a lookup table of category names: > > Administration/development tools > Programming interfaces > Clustering/replication > Procedural languages > Reporting tools > PostgreSQL extensions > Applications > ?? > > The licence type codes will be hardcoded: > > 'o' - Open Source > 'c' - Commercial > 'f' - Freeware > > Sound reasonable? Anything I've missed? Products may have more than one category and more than one license. The above schema handles these things. Might we want to break "publisher" out into a separate table? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Mon, Jun 2, 2008 at 12:33 PM, David Fetter <david@fetter.org> wrote: >> price text -- Pricing info (where relevant) > > Price is too complicated to model, and suffers from "cache coherency" > issues. Pointing to a web site, where appropriate, would handle this > better. Agreed but a) we already display that data and b) it's useful to give users a ballpark figure, even if something like "$99.99US as at 15/12/2007" <snip ddl> > Products may have more than one category. We don't currently allow listings in more than one category, and I'm inclined to continue with that (unwritten) policy - the reason being that listing in multiple categories will easily bloat the number of generated pages that a product might be listed in, potentially affecting search engine rankings. With relatively generic categories I don't see any real need to allow multiple categories. > and more than one license. Again, not sure I see a need. Either it's commercial, OSS, or freeware - I don't think there's much scope to have more than one (the obvious exception is something like "$99.99, or free to educational users" but I'd just class that as commercial). I don't want to list the actual OSS licence used as folks can decide whether a product meets with their personal ethics once they visit it's homepage. > The above schema handles these things. Might we want to break > "publisher" out into a separate table? Possibly. Makes the coding & management a little more tricky though. If we were to do that perhaps it should be part of a larger project to have a directory of vendors/publishers etc for news, events, services and products. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Monday, June 02, 2008 04:33:49 -0700 David Fetter <david@fetter.org> wrote: > Price is too complicated to model, and suffers from "cache coherency" > issues. Pointing to a web site, where appropriate, would handle this > better. Agreed .. would just listed it as 'OSS, shareware vs commercial' ... - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhD5TUACgkQ4QvfyHIvDvN8xACgpJwi95crfoWZDCUudhGOcAp1 UbUAn1iOi6nfLi3AF72GGSimWmN/5QTG =MMfW -----END PGP SIGNATURE-----
Dave Page wrote: > I'm looking at replacing the ad-hoc lists of products at > http://www.postgresql.org/download/ and > http://www.postgresql.org/download/commercial with a product > directory. I'd like to keep it fairly simple, and propose the > following data be stored: > > id serial primary key -- easier in the framework, complaints to /dev/null > publisher text -- Company/person/project name > publisher_url text -- Company/person/project URL > product text -- Product name > product_url text -- URL for the product > category int4 -- Category ID (fkey -> categories table) > description text -- Product description > price text -- Pricing info (where relevant) > licence char(1) -- Licence type flag > I would push publisher and publisher_url to their own table. Further we may really want to consider that a publisher could be a sponsor. We don't want to duplicate all this info. Sincerely, Joshua D. Drake
Dave Page wrote: > On Mon, Jun 2, 2008 at 12:33 PM, David Fetter <david@fetter.org> wrote: > >>> price text -- Pricing info (where relevant) >> Price is too complicated to model, and suffers from "cache coherency" >> issues. Pointing to a web site, where appropriate, would handle this >> better. > > Agreed but a) we already display that data and b) it's useful to give > users a ballpark figure, even if something like "$99.99US as at > 15/12/2007" I have to go with fetter here. Pricing is not our concern. > >> and more than one license. > > Again, not sure I see a need. Either it's commercial, OSS, or freeware > - I don't think there's much scope to have more than one (the obvious > exception is something like "$99.99, or free to educational users" but > I'd just class that as commercial). I don't want to list the actual > OSS licence used as folks can decide whether a product meets with > their personal ethics once they visit it's homepage. > +1 >> The above schema handles these things. Might we want to break >> "publisher" out into a separate table? > > Possibly. Makes the coding & management a little more tricky though. > If we were to do that perhaps it should be part of a larger project to > have a directory of vendors/publishers etc for news, events, services > and products. Yeah I mentioned this in my previous post. Publisher really needs to be pushed out. There is entirely too much redundant information that can be accumulated. Sincerely, Joshua D. Drake
On Mon, Jun 2, 2008 at 4:28 PM, Joshua D. Drake <jd@commandprompt.com> wrote: >> Agreed but a) we already display that data and b) it's useful to give >> users a ballpark figure, even if something like "$99.99US as at >> 15/12/2007" > > I have to go with fetter here. Pricing is not our concern. I actually feel quite strongly about that one - it's not *our* concern, but it is the concern of the users. There's nothing worse than researching a product, and eventually finding out after trawling the website for half an hour that it's way too expensive. As an end-user I always wanted to see a ballpark figure up front. >> Possibly. Makes the coding & management a little more tricky though. >> If we were to do that perhaps it should be part of a larger project to >> have a directory of vendors/publishers etc for news, events, services >> and products. > > Yeah I mentioned this in my previous post. Publisher really needs to be > pushed out. There is entirely too much redundant information that can be > accumulated. OK so the difficulty here/previously is that you are essentially saying I need to write a publisher management system and a product management system, and update sponsors, news, events, services etc to use that data as well. Nice in theory, but not something I have time to do. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Mon, Jun 02, 2008 at 12:58:49PM +0100, Dave Page wrote: > > Again, not sure I see a need. Either it's commercial, OSS, or freeware > - I don't think there's much scope to have more than one (the obvious > exception is something like "$99.99, or free to educational users" but > I'd just class that as commercial). Seems like you need a "multiple" class, then. (Dual licenses are pretty common.) A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/
On Mon, 2008-06-02 at 16:46 +0100, Dave Page wrote: > > I have to go with fetter here. Pricing is not our concern. > > I actually feel quite strongly about that one - it's not *our* > concern, but it is the concern of the users. There's nothing worse > than researching a product, and eventually finding out after trawling > the website for half an hour that it's way too expensive. As an > end-user I always wanted to see a ballpark figure up front. And who is going to make sure the pricing is up to date? (hint: no one will) > > Yeah I mentioned this in my previous post. Publisher really needs to be > > pushed out. There is entirely too much redundant information that can be > > accumulated. > > OK so the difficulty here/previously is that you are essentially > saying I need to write a publisher management system and a product > management system, and update sponsors, news, events, services etc to > use that data as well. Nice in theory, but not something I have time > to do. But I am sure you have time to create a secondary table and the code for it. I am not asking you to create all the code for sponsors, news, events. I am asking you to use a reusable design so others can create code for those services. Sincerely, Joshua D. Drake >
On Mon, Jun 2, 2008 at 4:56 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > > And who is going to make sure the pricing is up to date? (hint: no one > will) I'm guessing you didn't read all of the thread? > But I am sure you have time to create a secondary table and the code for > it. I am not asking you to create all the code for sponsors, news, > events. I am asking you to use a reusable design so others can create > code for those services. That I can do. It sounded like you wanted me to get rid of all the redundant info at the same time. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Mon, 2008-06-02 at 17:02 +0100, Dave Page wrote: > On Mon, Jun 2, 2008 at 4:56 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > > > > And who is going to make sure the pricing is up to date? (hint: no one > > will) > > I'm guessing you didn't read all of the thread? > I may have missed that. Let me review again. > > But I am sure you have time to create a secondary table and the code for > > it. I am not asking you to create all the code for sponsors, news, > > events. I am asking you to use a reusable design so others can create > > code for those services. > > That I can do. It sounded like you wanted me to get rid of all the > redundant info at the same time. :) Sincerely, Joshua D. Drake
On Mon, 2008-06-02 at 17:02 +0100, Dave Page wrote: > On Mon, Jun 2, 2008 at 4:56 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > > > > And who is going to make sure the pricing is up to date? (hint: no one > > will) > > I'm guessing you didn't read all of the thread? Dave made a good point to me on Jabber about the pricing issue. Basically, I don't buy software so this issue doesn't quite sit right with me. He is right, I license very little commercial software for business purposes. In fact the *only* commercial software CMD has purchased is QuickBooks. So I am going to drop my argument against this. Sincerely, Joshua D. Drake
Please excuse the top-post (limitation of Jesus phone + gmail) Thinking about this on the drive home, it seem a price range would give the user an indication of whether to consider a package further, and be relatively maintenance-free. E.g. $0.00 - $99.99 $100.00 - $249.99 $250.00 - $499.99 $500.00 - $999.99 $1000.00 - $4999.99 $5000.00+ On 6/2/08, Joshua D. Drake <jd@commandprompt.com> wrote: > > > On Mon, 2008-06-02 at 17:02 +0100, Dave Page wrote: >> On Mon, Jun 2, 2008 at 4:56 PM, Joshua D. Drake <jd@commandprompt.com> >> wrote: >> > >> > And who is going to make sure the pricing is up to date? (hint: no one >> > will) >> >> I'm guessing you didn't read all of the thread? > > Dave made a good point to me on Jabber about the pricing issue. > Basically, I don't buy software so this issue doesn't quite sit right > with me. He is right, I license very little commercial software for > business purposes. In fact the *only* commercial software CMD has > purchased is QuickBooks. So I am going to drop my argument against this. > > Sincerely, > > Joshua D. Drake > > > > > -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Mon, Jun 2, 2008 at 11:35 AM, <dpage@pgadmin.org> wrote: > Please excuse the top-post (limitation of Jesus phone + gmail) > > Thinking about this on the drive home, it seem a price range would > give the user an indication of whether to consider a package further, > and be relatively maintenance-free. E.g. > > $0.00 - $99.99 > $100.00 - $249.99 > $250.00 - $499.99 > $500.00 - $999.99 > $1000.00 - $4999.99 > $5000.00+ I purchase software on a regular basis, and my buckets are something more like: 0-250 251-1000 1001-10000 10k+ And really, a useful categorization for filtering that speaks to both cost and use case would be: General Public Education Small to Medium-Sized business (individual to ~100 employees) Enterprise -selena -- Selena Deckelmann United States PostgreSQL Association - http://www.postgresql.us PDXPUG - http://pugs.postgresql.org/pdx Me - http://www.chesnok.com/daily
Dave, All: 1) I think this is a good idea. Thanks, Dave. 2) I don't think we should deal with price at all. It's too complicated. Imagine a product which is $500 retail, $3000 enterprise and $27.50 OEM. 3) Josh is right that we'll eventually want this to be linked to the sponsors list. So we should prepare for that somehow. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
On Monday 02 June 2008 16:55:49 Josh Berkus wrote:
> 2) I don't think we should deal with price at all. It's too complicated.
> Imagine a product which is $500 retail, $3000 enterprise and $27.50 OEM.
>
people want the pricing information, so i think usefullness is not the issue,
its how to capture non-standard input. I say punt it and just give a text box
for pricing. This would give the same level of information as what is
available now.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL