> From: [email protected] [mailto:discuss- > [email protected]] On Behalf Of Harvey Rothenberg > > Between Microsoft's SQL Server and PostGres (no matter the version) which > would be easier to install and maintain, in general ? Could you equate SQL > Server to Oracle in their flexiblity/complexity or is PostGres more > challenging > ?
Oh - You were clear from the start, saying MS SQL, not MySQL. My mistake. MymiStakeQL. ;-) > I am looking from the piont-of-view of a computer novice who has to select > one of these DB Engines that is supported by a needed application program > install. You said the above, and then you also said the below ... > But aren't some DB Engines better than others for specific industries or > types of applications for various reasons or has it gotten to the point that > it is just a matter of the choice of the person who is going to develop the > application and that is all that matters ? I like your comparison of Honda vs Ford. It's very much the same here. Yes, there are significant differences between a Honda and a Ford, if you happen to be an enthusiast or a mechanic or pit crew for a racing team. No, there's not a significant difference if you're a first time car buyer who wants to drive it. Most of the query language and syntax is the same - but not all. Which is like putting the controls in slightly different locations inside your drivers' seat in the car. If you build an application that depends on specifics of the DB, then you're making yourself inflexible to switch to a different DB. It is advisable in most cases, to build a layer of abstraction in your data model, away from the DB. So you could easily switch the underlying DB if you wanted to. But that's not always possible, and I don't have any simple way of telling you how to do that. >From the perspective of a novice, or from a technical person who's not usually >a DBA, they're both going to be just as good, and the main differences you'll >care about are things like how much the licensing & support & backups cost. >(In most cases, people pay for a license to add on to their enterprise backup >application, in order to back up the DB. But there are a thousand possible >backup solutions, and they don't all require monetary investement.) >From the perspective of a technical person who's not usually a DBA, you should >probably focus your effort elsewhere - Because there are pitfalls that affect >all databases. Your developers should *first* be aware of general DB >architecture practices. Make good choices about which fields in which tables >will be index fields, and understand how much work is necessary to perform >certain types of queries versus joins and stuff. Good DB table architecture matters a lot more than which engine is running it. In the world of cars, that is to say, First learn to be a good driver, before you think about tuning your engine. Because you tune your engine as a response to the way you intend to drive. It requires both a deep technical knowledge of how DB's work and how your application works, in order to make a significant distinction between different DB's and how they're configured. _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
