Re: Need for PostgreSQL demand?
От
Rob Napier
Тема
Re: Need for PostgreSQL demand?
Дата
Msg-id
C457E64B.54C4%rob@oncetechnologies.com
Список
Дерево обсуждения
Re: Need for PostgreSQL demand? Rob Napier <rob@oncetechnologies.com>
Re: Need for PostgreSQL demand? Decibel! <decibel@decibel.org>
Hi!
It seems that I dropped off the advocacy list last year and missed all the activity six months ago when once:radix was part of your discussion about a killer app.
Here is my take on our first year in the open source domain as a wannabe killer app:
once:radix has been compared to FileMaker and Microsoft Access. That’s not surprising since we are serving similar end-user requirements. e.g. We have a client in Western Australia where about 40 people connect to a local server while another 15 people work out of their office in Melbourne. That’s about the same distance as New York to LA or London to Istanbul. The company currently has about 6,000 jobs in their system, created over the past 10 months. They have more than 3000 client and supplier contact records, project data, time sheets, requests for quotation, purchase orders, invoices, and so on. And it links to a back-end accounting package.
The system gets worked pretty hard over a basic 2 Mbps link between their offices. I doubt that a competitor product could achieve the same outcome without spending a fortune on Citrix clients.
But connectivity questions aside, is our application equal to an average Filemaker or Access app? I would have to say no. Having PostgreSQL as the underlying database allows our designers to build considerably more advanced systems.
But then, do people want to build such sophisticated systems? Again, most of the time, the answer is no, but the knowledge that systems can grow without running out of steam should give IT managers confidence that they are investing in a long-term solution.
I should think that more than 80% of competitor applications use only a few tables with very simple joins. At best, most would write only simple scripts (if any). This level of complexity can easily be accomplished in once:radix. And with the GUI screen design tools and database editor (all in a web browser) and a basic understanding of application development and database design, almost anyone can build equivalent applications that can be deployed via browsers.
If serious database designers feel tempted to look down their noses at the low end of the market, remember that Sun thought enough of MySQL to pull a billion dollars out of petty cash to buy them. That would never have happened if they had not first won the hearts and minds of low-end users.
Josh Berkus is right. A development and delivery environment that makes PostgreSQL more accessible could have a dramatic impact on its popularity. We have placed that technology in the public domain. We could achieve so much if some of the PostgreSQL community took a more proactive role in helping us make once:radix available to a wider community?
But we are not waiting for things to happen. once:technologies has moved its focus onto producing documentation that pitches the system to less experienced users, while also improving the information available to developers at the top end of our target market. We hope that by addressing both levels, we will begin to see a broader market acceptance.
Looking at our own application development, we try to keep things simple; but we sometimes have to resort to some pretty ambitious database design. He is an example of one relationship:
condition = join = "contacts_personmember" LEFT OUTER JOIN "contacts_person" ON ("contacts_person"."primary" = "contacts_personmember"."fk_person") LEFT OUTER JOIN "contacts_addressdefault" ON ("contacts_person"."primary" = "contacts_addressdefault"."fk_person" AND "contacts_addressdefault"."primary" = "contacts_personmember"."fk_addressdefault") LEFT OUTER JOIN "contacts_levelstructure" ON ("contacts_levelstructure"."primary" = "contacts_personmember"."fk_level") LEFT OUTER JOIN "contacts_organization" ON ("contacts_organization"."primary" = "contacts_levelstructure"."fk_organization") LEFT OUTER JOIN "contacts_branch" ON ("contacts_organization"."primary" = "contacts_branch"."fk_organization" AND "contacts_branch"."primary" = "contacts_levelstructure"."fk_branch") LEFT OUTER JOIN "contacts_client" ON ("contacts_client"."primary" = "contacts_personmember"."fk_client") LEFT OUTER JOIN "contacts_supplier" ON ("contacts_supplier"."primary" = "contacts_personmember"."fk_supplier")
LEFT OUTER JOIN "contacts_staff" ON ("contacts_staff"."primary" = "contacts_personmember"."fk_staff")
Sure, this example is not for the fainthearted but the great virtue of choosing PostgreSQL for once:radix is that when this level of database design (or more) is needed, we can deliver. Triggers and Functions, client and server-side scripting, rapid application development, there is all this and a whole lot more in once:radix. I wonder how the competition would handle some of the tasks we ask PostgreSQL to perform!
Our interface is more like a conventional client-server application than a web app. And that interface is part of the environment. For example, it doesn’t take special programming to create search, browse and edit modes. Also, searching in most fields take no more effort than a mouse click to return an indexed list of the contents of that field in the database.
We have a context-sensitive Help system with an inbuilt Apache Lucene search engine. It is really easy to document applications through that feature. Anyone with a basic sense of organisation and the ability to produce simple HTML can produce easy-to-access on-line help pages. And there is a lot, lot more – too much to cover here.
To date, we have built commercial applications for four quite different vertical markets; and now support clients in Australia, North America, the Caribbean and Europe. We have enough practical experience to be confident that our technology is fast, stable, secure and reliable.
So what has happened to the open source project over the past year?
Well there have been over 2000 downloads on SourceForge, representing almost 70 GB of data transfer. Not a huge number when measured against many open source projects, but still quite credible. We had hoped that people would come forward to help. To date, the response has been disappointing.
We are a small business. If we’d had the resources of even a mid-sized competitor, our position would be very different today and PostgreSQL would benefit from it. We invested a couple of million dollars in product development. Like the marketing of PostgreSQL, now comes the hard part: Finding distribution channels, building market share, recruiting strategic partners, et al. This is always the most challenging phase in bringing new technology to market.
We are still in there swinging!
Regards
Rob Napier
Managing Director
once:technologies pty ltd
It seems that I dropped off the advocacy list last year and missed all the activity six months ago when once:radix was part of your discussion about a killer app.
Here is my take on our first year in the open source domain as a wannabe killer app:
once:radix has been compared to FileMaker and Microsoft Access. That’s not surprising since we are serving similar end-user requirements. e.g. We have a client in Western Australia where about 40 people connect to a local server while another 15 people work out of their office in Melbourne. That’s about the same distance as New York to LA or London to Istanbul. The company currently has about 6,000 jobs in their system, created over the past 10 months. They have more than 3000 client and supplier contact records, project data, time sheets, requests for quotation, purchase orders, invoices, and so on. And it links to a back-end accounting package.
The system gets worked pretty hard over a basic 2 Mbps link between their offices. I doubt that a competitor product could achieve the same outcome without spending a fortune on Citrix clients.
But connectivity questions aside, is our application equal to an average Filemaker or Access app? I would have to say no. Having PostgreSQL as the underlying database allows our designers to build considerably more advanced systems.
But then, do people want to build such sophisticated systems? Again, most of the time, the answer is no, but the knowledge that systems can grow without running out of steam should give IT managers confidence that they are investing in a long-term solution.
I should think that more than 80% of competitor applications use only a few tables with very simple joins. At best, most would write only simple scripts (if any). This level of complexity can easily be accomplished in once:radix. And with the GUI screen design tools and database editor (all in a web browser) and a basic understanding of application development and database design, almost anyone can build equivalent applications that can be deployed via browsers.
If serious database designers feel tempted to look down their noses at the low end of the market, remember that Sun thought enough of MySQL to pull a billion dollars out of petty cash to buy them. That would never have happened if they had not first won the hearts and minds of low-end users.
Josh Berkus is right. A development and delivery environment that makes PostgreSQL more accessible could have a dramatic impact on its popularity. We have placed that technology in the public domain. We could achieve so much if some of the PostgreSQL community took a more proactive role in helping us make once:radix available to a wider community?
But we are not waiting for things to happen. once:technologies has moved its focus onto producing documentation that pitches the system to less experienced users, while also improving the information available to developers at the top end of our target market. We hope that by addressing both levels, we will begin to see a broader market acceptance.
Looking at our own application development, we try to keep things simple; but we sometimes have to resort to some pretty ambitious database design. He is an example of one relationship:
condition = join = "contacts_personmember" LEFT OUTER JOIN "contacts_person" ON ("contacts_person"."primary" = "contacts_personmember"."fk_person") LEFT OUTER JOIN "contacts_addressdefault" ON ("contacts_person"."primary" = "contacts_addressdefault"."fk_person" AND "contacts_addressdefault"."primary" = "contacts_personmember"."fk_addressdefault") LEFT OUTER JOIN "contacts_levelstructure" ON ("contacts_levelstructure"."primary" = "contacts_personmember"."fk_level") LEFT OUTER JOIN "contacts_organization" ON ("contacts_organization"."primary" = "contacts_levelstructure"."fk_organization") LEFT OUTER JOIN "contacts_branch" ON ("contacts_organization"."primary" = "contacts_branch"."fk_organization" AND "contacts_branch"."primary" = "contacts_levelstructure"."fk_branch") LEFT OUTER JOIN "contacts_client" ON ("contacts_client"."primary" = "contacts_personmember"."fk_client") LEFT OUTER JOIN "contacts_supplier" ON ("contacts_supplier"."primary" = "contacts_personmember"."fk_supplier")
LEFT OUTER JOIN "contacts_staff" ON ("contacts_staff"."primary" = "contacts_personmember"."fk_staff")
Sure, this example is not for the fainthearted but the great virtue of choosing PostgreSQL for once:radix is that when this level of database design (or more) is needed, we can deliver. Triggers and Functions, client and server-side scripting, rapid application development, there is all this and a whole lot more in once:radix. I wonder how the competition would handle some of the tasks we ask PostgreSQL to perform!
Our interface is more like a conventional client-server application than a web app. And that interface is part of the environment. For example, it doesn’t take special programming to create search, browse and edit modes. Also, searching in most fields take no more effort than a mouse click to return an indexed list of the contents of that field in the database.
We have a context-sensitive Help system with an inbuilt Apache Lucene search engine. It is really easy to document applications through that feature. Anyone with a basic sense of organisation and the ability to produce simple HTML can produce easy-to-access on-line help pages. And there is a lot, lot more – too much to cover here.
To date, we have built commercial applications for four quite different vertical markets; and now support clients in Australia, North America, the Caribbean and Europe. We have enough practical experience to be confident that our technology is fast, stable, secure and reliable.
So what has happened to the open source project over the past year?
Well there have been over 2000 downloads on SourceForge, representing almost 70 GB of data transfer. Not a huge number when measured against many open source projects, but still quite credible. We had hoped that people would come forward to help. To date, the response has been disappointing.
We are a small business. If we’d had the resources of even a mid-sized competitor, our position would be very different today and PostgreSQL would benefit from it. We invested a couple of million dollars in product development. Like the marketing of PostgreSQL, now comes the hard part: Finding distribution channels, building market share, recruiting strategic partners, et al. This is always the most challenging phase in bringing new technology to market.
We are still in there swinging!
Regards
Rob Napier
Managing Director
once:technologies pty ltd
В списке pgsql-advocacy по дате отправления
От: Susanne Ebrecht
Дата:
