On Thu, 19 Feb 2015 12:26:04 -0800 (PST), ru...@yahoo.com wrote: > >I'll point out that five people in this thread (by my >count) have said that Postgresql requires a significant >amount of work to setup and use. Only you and Steven claim >the opposite.
Well, I claim the opposite too. >Or I could have tried as you >and Steven suggest to "somehow" package Postgresql in my >app installer. That would have been an even bigger cost >in my time with an uncertain outcome. I don't see how. You said it was just a simple application this postgres database was serving. So I must assume you aren't talking of a complex setup that database synchronization or other features that force a manual setup. For your purposes, you could just basically backup your data folder and package postgres with the same configuration files you have in your current computer. >None of those >costs would have been necessary at all had I developed >a self-contained Sqlite app. The cost would have probably been much higher, depending on your project. SQLite would have forced you to move all your business logic into your code, greatly increasing code maintenance, your application extensibility and its ability to more easily adapt to new business requirements. Conversely, if none of this is true concerning your particular project, then you just chose the wrong tool. Postgres was overkill for your particular needs and it was a mistake to think you need it to function just as a shelve on steroids. > >Finally keep in mind that if you develop your app using >Sqlite, it is likely to be far easier to migrate to >a heavy-duty backend like Postgresql later should you >need to than to go in the other direction when you find >out you didn't really need Postgresql after all and the >cost turned out to be higher than you expected. Completely not true! For the reasons mentioned above. You are concentrating too much on the RDBMS aspects and completely forgetting about the implications in your codebase. Whether you move from a non distributed model to a client-server model, or the other way around, your code will suffer major changes. And even if you decide to keep the business logic in the client layer (which is a mistake) when moving from SQLite to a client-server RDBMS, you will still have to deal with a whole new set of issues regarding the very nature of concurrent access that will essentially force you to scrap much of your previous code. >It is bad advise to recommend using Postgresql without >regard to the developer's actual needs. Naturally. But I must say postgres isn't the bad cat you painted in your post. It's much, much easier to distribute, deploy and manage than you are suggesting. For most systems where performance and database synchronization aren't a requirement, it can be entirely automated, I know, because that's how we had it set up on three schools where we sold our integrated management system. I haven't had a maintenance request call in 8 months. It's only under critical requirements that postgres necessitates a baby sitter. And those projects don't suffer from lack of competent administrators. -- https://mail.python.org/mailman/listinfo/python-list
