Re: [HACKERS] Enticing interns to PostgreSQL - Mailing list pgsql-advocacy

Jim C. Nasby wrote:

>On Tue, Jul 26, 2005 at 01:53:54PM -0700, Chris Travers wrote:
>
>
>>Jim C. Nasby wrote:
>>
>>
>>
>>>And what do we use as a platform for this?
>>>
>>><dons flame suit> Should we have a "Why you probably don't want to use
>>>MySQL" document somewhere on the site?
>>>
>>>
>>>
>>>
>>>
>>It would be better to have a "Benefits over MySQL" page.  Something like:
>>
>>
>
>Well, I guess that's a more polite way to put it, but it misses the real
>point: MySQL does a lot of things that are at best not a very good way
>to do them and at worst put your data at serious risk. Many people
>simply have no idea about these issues. So while it'd be nice if these
>people chose PostgreSQL over MySQL, I personally think it's more
>important that they save themselves (and others) the pain that's likely
>to follow from deciding to use MySQL.
>
>
While you are correct in pointing this out, there is an issue here.  Do
we really want to position ourselves as talking bad about our
competition publically?  I say we don't simply because it is a very good
way to drive away potential users.

Also there is something to be said about not comparing yourself too much
to your competition in the commercial world though much of this doesn't
really apply here in the FOSS world.  What I would like to see, however,
are two things:

1)  A maintained features card comparing FOSS databases.  We could add a
feature to the list called "Strict data integrity enforcement."
2)  A maintained features card comparing PostgreSQL and commercial
databases.RDBMS's.


>BTW, your list is missing some critical items, such as silent data
>truncation, count(*) returning an estimate, how there's numerous ways to
>configure MySQL so it's not ACID without even knowing it, etc. In other
>words, problems that make it easy to trash your data (without even
>knowing it), as opposed to standard database features that are just
>missing.
>
>
I agree to an extent.  I just don't want to see the community position
ourselves as being unprofessionally opposed to our main FOSS
competition.  I think that this will drive users *away* rather than *to*
PostgreSQL.

>
>
>>In fact, having a maintained feature sheet listing PostgreSQL, MySQL,
>>and FirebirdSQL probably wouldn't be a bad idea.
>>
>>
>
>That's probably not a bad idea either, just to give people an idea of
>how the different projects stack up. SQLlite would probably be a good
>addition to that list as well.
>
>
And Ingress II, as well, as I think about it.

>
>>>But as you mentioned, if we're careful with syntax the type can always
>>>be expanded. Another interesting use case would be an enum that
>>>automatically adds new values to the lookup table if they don't already
>>>exist. I know it's no longer an enum in the traditional sense, but this
>>>is a common enough use case that it would be very convenient to have.
>>>
>>>
>>>
>>>
>>This could be done with triggers and deferred RI constraints.  However,
>>how does it differ from a VARCHAR?
>>
>>
>
>I know it can be done now; I'm just saying it would make the developers
>job a bit easier.
>
>
>
>As for varchar, they're orthogonal issues. If you have a large table
>with a limited number of text values that could change over time you'd
>want to store an integer ID in the large table, but make it easy to deal
>with new values being added.
>
>
So basically here you are looking for a type which will automatically
keep track of a limited number of used values.

I will say I don't like this option because it feels like premature
optimization, and would rather take my time with an index scan.  And
where it is useful, I think it is often added after the fact.

Best Wishes,
Chris Travers
Metatron Technology Consulting