Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

(jeffa) Re: Comparison, questions for Postgres, MySQL

by jeffa (Bishop)
on Oct 08, 2002 at 00:16 UTC ( #203536=note: print w/replies, xml ) Need Help??

in reply to Comparison, questions for Postgres, MySQL

When i first started working at with maverick and eduardo, i asked mav this very question. We were using MySQL at the time, and he explained that the MySQL people were more interested in speed than features. Conversely, the Postgres people were more interested in features than speed. Since we didn't need transactions or inner selects and we did need speed, maverick chose MySQL.

Flash forward to now. Postgres has managed to finally catch up with MySQL in the speed department, but MySQL is still behind Postgres in the feature department. Me? I still use MySQL simply from habit, but i still haven't worked on anything serious enough that requires triggers or transactions. RI, views, and inner selects are good, but not completely necessary. If you need them or anticipate needing them (or any of the other features that Postgres has), use Postgres. As long as you are using Perl, you will be smiled upon favorably by the Gods. ;)


(the triplet paradiddle with high-hat)
  • Comment on (jeffa) Re: Comparison, questions for Postgres, MySQL

Replies are listed 'Best First'.
Re: (jeffa) Re: Comparison, questions for Postgres, MySQL
by diotalevi (Canon) on Oct 08, 2002 at 00:25 UTC

    You know... there is one thing that is either available in non-perl implementations for PostgreSQL that might make me envious of MySQL (assuming it has the feature). asynchronous queries. It galls me that the DBD::Pg driver has to fully complete the PostgreSQL query, copy the data into perl-space and /then/ you can work with it. (it might do lazy copying but that isn't the point). I'd really like it if PostgreSQL got that feature and for some uses that would be a Killer Feature. That's more a function of the existing driver though since PostgreSQL supports it, we just aren't taking advantage of it (yet). Or is there some reason that DBI can't handle aio?

    __SIG__ printf "You are here %08x\n", unpack "L!", unpack "P4", pack "L!", B:: +svref_2object(sub{})->OUTSIDE
Re: Comparison, questions for Postgres, MySQL
by Abigail-II (Bishop) on Oct 08, 2002 at 09:46 UTC
    Since we didn't need transactions
    I'm always stunned when I read such a thing. It makes me wonder why you are using a relational database in the first place. If you don't use transactions, I guess you don't care about the integrety of you data. But if you don't care about that, why have it in the first place?


      Why did we use a relational database... well, there is really a simple answer for that. We didn't for 1/2 of our project, and we did for the other 1/2. :) Let's look at what we built, shall we?

      The "project" at surfari consisted off two main products, a website and a search engine. The website needed to keep basic user information, such as username, password, favorite sites, personal bookmarks, etc... Now, I understand your "stunned" outrage at a statement like: Since we didn't need transactions... but, let's analyze why it is that our esteemed friend jeffa would make such a dangerous statement.

      When does one "need" transactions? Well, first and foremost, when your data is valuable :) Let's analyze the different dimensions of data that we were storing, and let's see how transactions would have added value...

      • User information - Nope... it was a single "add user" button that pretty much just inserted or did not insert a user into the user table. Maverick's code checked the return status of that insert, and it was impossible for the user table to be left in an indeterminate state
      • User bookmarks - Well, let's see, you could either remove a bookmark, or add a bookmart to the bookmark table. This consisted of "look up the user id", and "add a bookmark ID to the bookmark table with a fake foreign index to the user id." Hm... doesn't really seem like the data could have been left in an indeterminate state here either...
      • Visit tracking - Let's see, each time the user hit a webpage, we stored where they'd come from (thank you HTTP referer!) where they were, etc... we didn't store how long they'd taken to get there, because we could batch process the time dimensionality offline and not negatively impact user experience. So, let's see, another atomic addition to a singular table... yet again, Transactions would not have helped us out here.
      • User preferences - Ah, customization! This was going to be what was going to make my 10% of the company in stock options enough to retire... you see, the user would love to spend hours on a shopping mall website setting up their own private color scheme! well, let's see, each time they changed a parameter, an update was fired off to their "customizations" entry for that particular parameter. Hm... another singular atomic transaction. Crap.

      Hm... So, why were we using a relational database in the first place?

      We were using the ability to store "fake foreign keys" (referential integrity wasn't insured by MySQL, but that's ok, it didn't change the value of our data) with great ease. We had an *incredibly* nice interface to a very customizable persistent data store... We had a really nice query language for our data store... and When we started doing collaborative filtering (Other users that like this stuff liked this other stuff), having it all in a relational database made that development *super fast*! Not to mention that with "time to market" constraints of Internet time, the fact that it provided all of this super duper functionality in an API we all already knew and loved made choosing MySQL a no-brainer. None of the features of the, admittedly incredible, Postgress would have made 1 lick of difference... after all, it's not like we were:

      Removing 100 dollars from debit table.
      Adding 100 dollars to credit table.

      :) God I love classical examples.

      So, where didn't we use relational databases? In our search engine! We took a DEC Alpha optimized B-Tree library, put an advanced forest-and-trees tree balancing and distributing decision walker in front of it, added a *sweet* splay-like aging cache mechanism in front of it to alleviate the von-neumann bottleneck, and took advantage of log2(n) as much as we could :)

      So... did we care about the integrity of our data? Sure! We were going to retire from the IPO... however, in *many* of the applications I have faced in my professional life, (which granted, have *not* been in the financial sector), all "logical transactions" have been of single statement cardinality.

      I advocate right tool for the right job... and in this case, the only reason a relational database was used was the really sweet query interface to a persistent data store, and the handy dandy functionaity provided by auto-increments, indexing, etc... I can guarantee you that any time I see a more complex data model, I reach for a transactional data store...

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://203536]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (5)
As of 2018-05-26 10:20 GMT
Find Nodes?
    Voting Booth?