Arthur Fuller
fuller.artful at gmail.com
Sun Sep 18 02:03:59 CDT 2011
I think you lost me there, JC. Which product do you think looks pretty nice? I think that you're ultimately right about Larry's intentions. No sense in killing the cash cow for the NGOs etc. But to be fair, insofar as I can be, why would Oracle buy Sun and by inheritance MySQL? Perhaps these are separate questions, perhaps not. In what sense is it in Larry's interest to crush MySQL? Granted, they have lots of heavyweight customers and granted, it's easy enough to extract from them some annual fee, but is that Larry's intention? To throttle the free versions until the only customers might be a mom'n'pop donut shop with a daughter in first year CS? Frankly, I don't get it. So there are two big choices, depending on your needs: a) relational, transactional, ACID etc..... go PostGreSQL b) massive scalability (100K hits a minute) and principle task is to retrieve text to fill a web page. These are radically different demands, and I don't think it possible for one product to satisfy both. For the former situation, something like Oracle or MS SQL Server or Sybase or PostGreSQL or MySQL is appropriate. For the latter category, all the former fall dismally short of the requirements. Category b makes no bones about its demands, in terms of hardware. Be prepared to throw lots and lots of hardware at this zapproach, because the whole idea is that the entire database lives in RAM. In many situations, that is impossible, but if so, think instead that all the indexes and the most popular hits live in RAM, with the rest available within a second -- and this applies to 100,000 or 1,000,000 simultaneous users. That's the crucial difference. Actually, there are two differences. The first case involves a lot more data-entry than the second. or to put it another way, the second case wants a lot more foreplay before concluding the transaction. In the first case, a customer phones or emails or faxes a purchase order, however casual. "I want that set of lawn chairs and the circular table and the umbrella. Delivered, please." In the second case, the login is searching for information. It could ultimately lead to a purchase, as in the case of Amazon or eBay, but it could also be a pure search for information, as in the case of most wikiPedia hits. Many sites have combined these two scenarios, Google and Amazon and Netflix notably. So, the design question becomes, do we use two different databases, one for page retrieval and the other for transactions, or try to do it all in one? The all-in-RAM approach is dangerous for transactional integrity, so if we do the all-in-one approach, then it's got to be one of the relational database solutions mentioned above. But the performance hit is astronomical, so there we are. Perhaps the correct solution is two databases rather than one -- the first delivers all the content, and the second kicks in at transaction-time. The benchmarks of such products as Mongo and similar NoSQL implementations are phenomenal, given their preferred domain, retrieving mostly text for vast numbers of users at once. Yes, there are hardware demands, but given abundant RAM and thousands of hits per minute, this is clearly the way to go. And then at some point, the given views may or may not turn into a transaction, at which point the NoSQL front end could hand off a couple of IDs to the transactional engine, which would complete the transaction. I haven't yet worked out the transport mechanism for the hand-off from the "Mongo" (I use that term because it was the first such db I encountered, and not because I think it's the best) to the relational/transactional db. Several approaches come to mind, mitigated by external variables such as fixed-quantity vs. unlimited quantity (concert tickets vs. shirts), and that would have to be sorted out business by business. That does not refute the argument I am presenting here, which is that there are two requirements in operations such as Amazon, NetFlix, eBay and even wikiPedia. The first is to grab textual data as quickly as possible for a vast number of simultaneous users. The second is to undertake transactions once the users have made their selections. My conclusion is that the first task is better handled by an in-RAM database such as Mongo, and that the latter is better handled by a traditional relational database such as Oracle or SQL Server or Sybase or MySQL or PostGreSQL One hand-off method would be a queue such as one might implement in MSMQ, or simply write oneself. That only works in the world of unlimited quantities, however. In the world of fixed-inventory (400 tickets to a soccer match, and no more can be acquired), simple queues won't work, because people want to know *now* whether they've got their tickets. Between these extremes are many other situations wherein supply versus demand figures in various subtle ways. But I digress. The question I want to raise is, What do you think of the distinction I am trying to make, and my proposition that in situations like these, two dbs (and implementation styles) are better than one? A. On Sun, Sep 18, 2011 at 2:01 AM, Jim Lawrence <accessd at shaw.ca> wrote: > Postgesql and Postgres Plus are the heirs apparent. They can now do what > MySQL will ever be allowed to do and that is become an enterprise database. > Oracle has no intention of building a free competitor. > > Read more: http://www.postgresql.org/, > http://en.wikipedia.org/wiki/PostgreSQL and > > http://www.enterprisedb.com/products-services-training/products/postgres-plu > s-advanced-server > > There are lots of documents and samples and the product is very stable. > There has been a lot of excitement with the latest versions. > > Jim > > > -----Original Message----- > From: dba-sqlserver-bounces at databaseadvisors.com > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Saturday, September 17, 2011 6:53 PM > To: Discussion concerning MS SQL Server > Subject: Re: [dba-SQLServer] [AccessD] MySQL > > There are some nice things about MySQL but on the other hand I definitely > do > not like where Oracle is going with this puppy since its acquisition of Sun > and by inheritance MySQL. I'm still on the fence about these developments, > but quite frankly I am leaning against Oracle on all these transmutations > of > what was originally a simple, straightforward approach. At last > recollection, Monty has departed, and with him, I fear, has the guiding > vision of this product. > > Frankly, I am all over the place on where next to go: I look at Mongo and > see it exquisite for web-apps but not for OLTP situations. I look at > PostGreSQL and think it's got a bunch of things right. I look at Oracle and > MS-SQL and think they have some things right as well. I frankly do not have > any clue into which basket to toss my next eggs. > > Arthur > > On Sat, Sep 17, 2011 at 7:51 PM, Stuart McLachlan > <stuart at lexacorp.com.pg>wrote: > > > I run MySQL locally as part of a WAMP installation and remotely on our > > FreeBSD servers. > > > > I use phpMyAdmin for all the administration. It's a very intuitive > > interface. > > > > It's possibly worth installing WAMP just for the phpMyAdmin. > > > > -- > > Stuart > > > > > > On 17 Sep 2011 at 19:24, jwcolby wrote: > > > > > For now I have to figure out how to create a database. Is it the same > > > concept as SQL Server? A file or set of files where tables, indexes, > > > views etc are stored? I assumed there would be some visual designer > > > that would allow me to create the db, then tables etc. It looks like > > > that stuff is in "SQL Development". > > > > > > This thing looks pretty nice, but very different on the surface. > > > > > > > > > _______________________________________________ > > dba-SQLServer mailing list > > dba-SQLServer at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > http://www.databaseadvisors.com > > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > >