Java web application frameworks / architecture

Discussion in 'Java' started by barbara.streusand@yahoo.ca, Sep 22, 2009.

  1. Guest

    Hi experts:

    My company wants me to design and develop a new web application based
    on Java and Tomcat.
    I am not sure what the currently state of the art is in regards to
    web application frameworks.
    Please advice.

    The application will be based on a MySQL database with approx. 40
    tables and approx. 75 use cases (there is actually an application on
    PHP which is to be replaced, but the database should stay as is.)

    Requirements:
    - Authentication and authorization on a detailled level neccessary
    - Database access with some kind of ORM
    - Webservices (offering and consuming)
    - Heavy use of Ajax

    Currently I am thinking about Spring MVC, Struts 2.0, Wicket, Grails
    etc.

    Please advice,
    Thanks
    Barbara
    , Sep 22, 2009
    #1
    1. Advertising

  2. Arne Vajhøj Guest

    wrote:
    > My company wants me to design and develop a new web application based
    > on Java and Tomcat.
    > I am not sure what the currently state of the art is in regards to
    > web application frameworks.
    > Please advice.
    >
    > The application will be based on a MySQL database with approx. 40
    > tables and approx. 75 use cases (there is actually an application on
    > PHP which is to be replaced, but the database should stay as is.)
    >
    > Requirements:
    > - Authentication and authorization on a detailled level neccessary
    > - Database access with some kind of ORM
    > - Webservices (offering and consuming)
    > - Heavy use of Ajax
    >
    > Currently I am thinking about Spring MVC, Struts 2.0, Wicket, Grails
    > etc.


    I would go for JSF, Hibernate, Axis2 and Richfaces. And use container
    managed security.

    Arne
    Arne Vajhøj, Sep 22, 2009
    #2
    1. Advertising

  3. Lew Guest

    Arne Vajhøj wrote:
    > I would go for JSF, Hibernate, Axis2 and Richfaces. And use container
    > managed security.


    +1

    Also Postgres for the back end.

    --
    Lew
    Lew, Sep 22, 2009
    #3
  4. Lew wrote:
    > Arne Vajhøj wrote:
    >> I would go for JSF, Hibernate, Axis2 and Richfaces. And use container
    >> managed security.

    >
    > +1
    >
    > Also Postgres for the back end.
    >

    The OP doesn't have any choice wrt the DB, apparently. However, I agree
    with the general choices.

    As far as Richfaces goes, I like the set of recommendations that the
    author of
    http://www.ibm.com/developerworks/java/library/j-richfaces/index.html
    has. Richfaces fits in well with those.

    Definite two-thumbs up regarding container-managed security. It's not
    100% yet for every person's requirements, but I think it best to start
    that way, and try to make it work. In the interests of fuller disclosure
    the OP ought also to be aware of possibilities like Spring Security
    (http://static.springsource.org/spring-security/site/features.html),
    once Acegi. The OP can refer also to
    http://thelabdude.blogspot.com/2009/04/user-authentication-registration-with.html.

    AHS
    Arved Sandstrom, Sep 22, 2009
    #4
  5. Guest

    On Sep 22, 5:11 am, Arved Sandstrom <> wrote:
    > Lew wrote:
    > > Arne Vajhøj wrote:
    > >> I would go for JSF, Hibernate, Axis2 and Richfaces. And use container
    > >> managed security.

    >
    > > +1

    >
    > > Also Postgres for the back end.

    >
    > The OP doesn't have any choice wrt the DB, apparently. However, I agree
    > with the general choices.
    >
    > As far as Richfaces goes, I like the set of recommendations that the
    > author ofhttp://www.ibm.com/developerworks/java/library/j-richfaces/index..html
    > has. Richfaces fits in well with those.
    >
    > Definite two-thumbs up regarding container-managed security. It's not
    > 100% yet for every person's requirements, but I think it best to start
    > that way, and try to make it work. In the interests of fuller disclosure
    > the OP ought also to be aware of possibilities like Spring Security
    > (http://static.springsource.org/spring-security/site/features.html),
    > once Acegi. The OP can refer also tohttp://thelabdude.blogspot.com/2009/04/user-authentication-registrati....
    >
    > AHS



    Does container managed security mean, that I must use a full blown
    J2EE server like JBoss?
    I'd rather stick to Tomcat.

    And yet another question: Wicket and Grails claim to be so much more
    simple than JSF etc. Is that true and
    can I achieve the same results with simpler frameworks as with JSF,
    Axis and Richfaces?
    AFAIK Grails also makes use of Hibernate and Spring.


    Thank you for your replies.
    , Sep 22, 2009
    #5
  6. Arne Vajhøj Guest

    wrote:
    > On Sep 22, 5:11 am, Arved Sandstrom <> wrote:
    >> Lew wrote:
    >>> Arne Vajhøj wrote:
    >>>> I would go for JSF, Hibernate, Axis2 and Richfaces. And use container
    >>>> managed security.
    >>> +1
    >>> Also Postgres for the back end.

    >> The OP doesn't have any choice wrt the DB, apparently. However, I agree
    >> with the general choices.
    >>
    >> As far as Richfaces goes, I like the set of recommendations that the
    >> author ofhttp://www.ibm.com/developerworks/java/library/j-richfaces/index.html
    >> has. Richfaces fits in well with those.
    >>
    >> Definite two-thumbs up regarding container-managed security. It's not
    >> 100% yet for every person's requirements, but I think it best to start
    >> that way, and try to make it work. In the interests of fuller disclosure
    >> the OP ought also to be aware of possibilities like Spring Security
    >> (http://static.springsource.org/spring-security/site/features.html),
    >> once Acegi. The OP can refer also tohttp://thelabdude.blogspot.com/2009/04/user-authentication-registrati....

    >
    > Does container managed security mean, that I must use a full blown
    > J2EE server like JBoss?
    > I'd rather stick to Tomcat.


    Any compliant web container including Tomcat supports container
    managed security.

    A full app server has additional security features for EJB etc., but
    I assume that you only want the web stuff.

    > And yet another question: Wicket and Grails claim to be so much more
    > simple than JSF etc. Is that true and
    > can I achieve the same results with simpler frameworks as with JSF,
    > Axis and Richfaces?
    > AFAIK Grails also makes use of Hibernate and Spring.


    Wicket/Stripes/Grails are different from traditional Struts/JSF.

    And try with a more simplistic approach.

    I think you should try them out and see if they appeal to you.

    But JSF would be the mainstream road forward. Mainstream does not
    imply better, but it does imply easier to find expertise.

    Arne
    Arne Vajhøj, Sep 22, 2009
    #6
  7. Lew wrote:
    > Arne Vajhøj wrote:
    >> I would go for JSF, Hibernate, Axis2 and Richfaces. And use container
    >> managed security.

    >
    > +1
    >
    > Also Postgres for the back end.


    That is one possibility.

    There are plenty of others.

    The original poster seems to be using MySQL.

    Which with InnoDB tables should work fine from Java as well.

    Arne
    Arne Vajhøj, Sep 23, 2009
    #7
  8. Lew Guest

    Arne Vajhøj wrote:
    > Lew wrote:
    >> Arne Vajhøj wrote:
    >>> I would go for JSF, Hibernate, Axis2 and Richfaces. And use container
    >>> managed security.

    >>
    >> +1
    >>
    >> Also Postgres for the back end.

    >
    > That is one possibility.
    >
    > There are plenty of others.
    >
    > The original poster seems to be using MySQL.
    >
    > Which with InnoDB tables should work fine from Java as well.


    For restricted values of "fine".

    --
    Lew
    Lew, Sep 23, 2009
    #8
  9. ck Guest

    On Sep 22, 4:24 am, ""
    <> wrote:
    > Hi experts:
    >
    > My company wants me to design and develop a new web application based
    > on Java and Tomcat.
    > I am not sure  what the currently state of the art is in regards to
    > web application frameworks.
    > Please advice.
    >
    > The application will be based on a MySQL database with approx. 40
    > tables and approx. 75 use cases (there is actually an application on
    > PHP which is to be replaced, but the database should stay as is.)
    >
    > Requirements:
    > - Authentication and authorization on a detailled level neccessary
    > - Database access with some kind of ORM
    > - Webservices (offering and consuming)
    > - Heavy use of Ajax
    >
    > Currently I am thinking about Spring MVC, Struts 2.0, Wicket, Grails
    > etc.


    I would suggest to use framework(s) that you/your developers have
    experience on. Using a framework about which you are not aware or
    don't have hands on experience, can give you nightmares, if you are
    time bound. If you have "time" to experiment with all these
    frameworks, I have nothing much to add, you might want to think of
    some feature and build a prototype on all the webapp frameworks that
    you are thinking of and choose the one that you feel right about.
    You might want to take a look at appfuse, which gives several
    combination of frameworks for web application development.
    I am not really sure if any of the frameworks suggested so far have a
    vast "ajax" support, in real life projects you end up writing barebone
    javascript to get things done, or at least that has been my experience
    with webapp frameworks in Java.

    --
    Ck
    ck, Sep 23, 2009
    #9
  10. On Sep 22, 2:58 pm, ""
    <> wrote:
    > On Sep 22, 5:11 am, Arved Sandstrom <> wrote:
    >
    >
    >
    > > Lew wrote:
    > > > Arne Vajhøj wrote:
    > > >> I would go for JSF, Hibernate, Axis2 and Richfaces. And use container
    > > >> managed security.

    >
    > > > +1

    >
    > > > Also Postgres for the back end.

    >
    > > The OP doesn't have any choice wrt the DB, apparently. However, I agree
    > > with the general choices.

    >
    > > As far as Richfaces goes, I like the set of recommendations that the
    > > author ofhttp://www.ibm.com/developerworks/java/library/j-richfaces/index.html
    > > has. Richfaces fits in well with those.

    >
    > > Definite two-thumbs up regarding container-managed security. It's not
    > > 100% yet for every person's requirements, but I think it best to start
    > > that way, and try to make it work. In the interests of fuller disclosure
    > > the OP ought also to be aware of possibilities like Spring Security
    > > (http://static.springsource.org/spring-security/site/features.html),
    > > once Acegi. The OP can refer also tohttp://thelabdude.blogspot.com/2009/04/user-authentication-registrati....

    >
    > > AHS

    >
    > Does container managed security mean, that I must use a full blown
    > J2EE server like JBoss?
    > I'd rather stick to Tomcat.
    >
    > And yet another question: Wicket and Grails claim to be so much more
    > simple than JSF etc. Is that true and
    > can I achieve the same results with simpler frameworks as with JSF,
    > Axis and Richfaces?
    > AFAIK Grails also makes use of Hibernate and Spring.
    >
    > Thank you for your replies.


    In my own experience JSF is very complex, especially if you start as a
    beginner. What I find even now (with approx 1.5 year experience in
    JSF) is that a lot of things that you regularly do with simpler
    frameworks require complex workarounds, because the JSF lifecycle is
    quite limited and not flexible.

    Wrt. Hibernate, I think it is a good library; however, starting from a
    legacy DB you might have to design your entity classes in an awkward
    way to adapt them to the database schema, and if the legacy schema is
    sufficiently badly designed (as unfortunately is often the case) you
    might be unable to exploit all the Hibernate features and have the bad
    design reflected to your entity classes.

    Spring is very handy even for simple applications, so I definitely
    suggest you use it.

    For webservices, I have used JAX-WS which is standard J2SE (client
    side) and J2EE (server side), and supposedly is simpler than Axis (but
    I never used Axis so I don't have first-hand experience).

    hth,
    Alessio
    Alessio Stalla, Sep 23, 2009
    #10
  11. Lew Guest

    Alessio Stalla wrote:
    > Wrt. Hibernate, I think it is a good library; however, starting from a
    > legacy DB you might have to design your entity classes in an awkward
    > way to adapt them to the database schema, and if the legacy schema is
    > sufficiently badly designed (as unfortunately is often the case) you
    > might be unable to exploit all the Hibernate features and have the bad
    > design reflected to your entity classes.


    First of all, having a bad database design is a very serious problem
    irrespective of whether you use Hibernate or another JPA product (OpenJPA,
    TopLink/EclipseLink). In this it is like any bad design in your system - it's
    going to hurt you. The pain is not linear with badness of design - it can be
    quadratic or geometric. On one project some years ago my team lead forbade me
    to normalize a relational database, thus requiring one report to run off of
    and filter the unconstrained join between two very large tables. Nothing I
    said convinced the team lead to let me normalize. ("I'm not changing the
    database at this late date - find another way to optimize the report."
    "Optimize". Sheesh.) When the report took days (or longer, who knows?) to
    run with production-scale tables they finally normalized, but not until they'd
    embarrassed themselves with their client. This was straight JDBC; we had no
    3rd-party ORM layer.

    Bad design gets reflected in your whole system, not just your entity classes.

    That said, your entity classes do not have to match your tables one-to-one.
    The idea isn't exactly to match entity classes to tables, it's to match entity
    classes to the object model of the application. If you have the luxury to
    design the database to support the system, you typically match tables to
    entities, but you aren't matching entities to tables.

    If the entities and tables do not match, that's where the mapping becomes
    tricky but not usually impossible.

    The biggest mistake people make with ORM packages is to use them to sustain a
    data model in the program. This is ORM abuse. You use them to sustain an
    object model in the program, and map it to a data model in the database.

    I know from experience in large-scale projects that treating your entity layer
    like a data layer can cause huge inefficiencies to emerge. If you use
    entities as part of the object model, Hibernate (OpenJPA, TopLink) are usually
    pretty good about caching and only hitting the database when they really need to.

    --
    Lew
    Lew, Sep 23, 2009
    #11
  12. Lew wrote:
    > Alessio Stalla wrote:

    [ SNIP ]

    > I know from experience in large-scale projects that treating your entity
    > layer like a data layer can cause huge inefficiencies to emerge. If you
    > use entities as part of the object model, Hibernate (OpenJPA, TopLink)
    > are usually pretty good about caching and only hitting the database when
    > they really need to.


    Although on the subject of caching and other things which are outside
    JPA, the usual caveat applies - read the documentation very carefully.
    Make sure the documentation is for exactly the software version that you
    have. Check with technical forums and blogs. *And* confirm that things
    that you expect to work actually do.

    As an example, an application that we are currently fixing for a client
    uses Toplink Essentials. Although the medium-term plan is to move to
    EclipseLink, right now we have to improve things with TLE. We have found
    that (and I recognize that many of these are reasonably well-known):

    1) JPA javax.persistence.Query setFirstResult() and setMaxResults()
    work...sort of. In TLE the full set of results is still returned from
    the database, and the Toplink implementation classes underlying
    javax.persistence.Query use JDBC methods like absolute() to filter what
    they build into the persistence context. So don't necessarily plan on
    using these JPA methods for an efficient paging strategy;

    2a) Caching does not work on queries. Period. As opposed to EM.find(),
    which checks the cache first, in TLE the use of queries (all queries)
    will always result in a hit to the database first. There are some
    efficiencies insofar as when results come back, if an instance of an
    entity is discovered in the cache that will be used instead, as opposed
    to being rebuilt, but that's it.

    You can get around this to some extent by using the native TLE API, and
    obviously if using EclipseLink there are cache hints that allow you to
    both cache static queries (same SQL, same bind parameters) and also
    returned result sets;

    2b) If you _have_ gotten down into Toplink Essentials API land (which is
    not unlikely if you are performance tuning), be cognizant of what query
    types cooperate with the cache and which do not.

    3) Don't forget about database caching (e.g. Oracle RAM data buffers).
    As a developer (or even tester) who uses certain known test data, you
    may delude yourself into thinking that your DB access code is pretty
    zippy. But for a real user whose data is varying, it's not.

    4) Lazy fetching: IOW, LAZY fetch _hints_ (and I stress the word hints)
    on 1:1 and M:1 relationships. TLE/Toplink/EclipseLink use ASM to modify
    the entity class bytecode to enable lazy instantiation of these
    relationships. At least with TLE, check your entity classes (if working
    in a container) to see if weaving actually kicked in. You may be surprised.

    5) Serialization of EntityManager implementation (e.g. for clustering):
    for TLE/Toplink 10g, and I think for Toplink 11/EclipseLink also, this
    just won't work. Similarly, extended persistence contexts will only work
    on the same JVM. The recommended way of implementing EM serialization
    using TLE/TL/EL is to write a wrapper that stores necessary entity
    information for a persistence context. Hibernate, I believe, does
    support serialization because Hibernate Sessions are Serializable, IIRC.

    This is just an example of ORM-specific issues. There are many more.

    As another example of performance mismatches between your entity layer
    and your business logic/user interface, that can be caused by a
    simplistic use of JPA (so ORM-agnostic), analyze your queries if you're
    using full entities in them. Especially if you're using joins in your
    JPQL. If there are no compelling performance reasons to change from full
    object notation in your JPQL, leave it alone. Full objects are cleaner.

    But occasionally you'll find that a full object JPQL query is generating
    dozens or hundreds (or worse) SELECT statements where strictly speaking
    you ought to be able to get all your data with *one*. This may well be
    the result of entity relationships that you cannot lightly change, and
    it can happen even without joins. If the performance hit is significant,
    one can always consider JPQL constructor expressions. These are brutally
    effective and do give you a sensible Java business object - not just a
    row wrapper - to use. You also avoid using native SQL.

    AHS
    Arved Sandstrom, Sep 23, 2009
    #12
  13. Lew wrote:
    > Arne Vajhøj wrote:
    >> Lew wrote:
    >>> Arne Vajhøj wrote:
    >>>> I would go for JSF, Hibernate, Axis2 and Richfaces. And use container
    >>>> managed security.
    >>>
    >>> +1
    >>>
    >>> Also Postgres for the back end.

    >>
    >> That is one possibility.
    >>
    >> There are plenty of others.
    >>
    >> The original poster seems to be using MySQL.
    >>
    >> Which with InnoDB tables should work fine from Java as well.

    >
    > For restricted values of "fine".


    Maybe restricted to web sites smaller than FaceBook and Wikipedia ...

    But give that PostgreSQL does not run any sites of the size
    that MySQL does then it will not be the replacement.

    Arne
    Arne Vajhøj, Sep 29, 2009
    #13
  14. Lew Guest

    Arne Vajhøj wrote:
    >> But give that PostgreSQL does not run any sites of the size
    >> that MySQL does then it will not be the replacement.


    Sabine Dinis Blochberger wrote:
    > It doesn't or couldn't? From what I heard, PostgeSQL can hold up with
    > the big ones. Any source to say different?


    Maybe he meant it the other way - PG doesn't run any sites that small.

    :)

    --
    Lew
    Lew, Sep 29, 2009
    #14
  15. Sabine Dinis Blochberger wrote:
    > Arne Vajhøj wrote:
    >> Lew wrote:
    >>> Arne Vajhøj wrote:
    >>>> Lew wrote:
    >>>>> Arne Vajhøj wrote:
    >>>>>> I would go for JSF, Hibernate, Axis2 and Richfaces. And use container
    >>>>>> managed security.
    >>>>> Also Postgres for the back end.
    >>>> The original poster seems to be using MySQL.
    >>>> Which with InnoDB tables should work fine from Java as well.
    >>> For restricted values of "fine".

    >> Maybe restricted to web sites smaller than FaceBook and Wikipedia ...
    >>
    >> But give that PostgreSQL does not run any sites of the size
    >> that MySQL does then it will not be the replacement.
    >>

    > It doesn't or couldn't?


    It doesn't.

    > From what I heard, PostgeSQL can hold up with
    > the big ones. Any source to say different?


    Not any technical source.

    Just the market.

    I am not aware of any really big PostgreSQL installations.

    It can be because all their CIO's are unaware of how good
    PostgreSQL is or it can be because PostgreSQL is not a good
    pick for the task.

    I consider the last a lot more likely than the first.

    Arne
    Arne Vajhøj, Sep 30, 2009
    #15
  16. Re: [OT] PostgreSQL was Re: Java web application frameworks / architecture

    Sabine Dinis Blochberger wrote:
    > Arne Vajhøj wrote:
    >
    >> Sabine Dinis Blochberger wrote:
    >>> Arne Vajh�¸j wrote:
    >>>> Lew wrote:
    >>>>> Arne Vajh�¸j wrote:
    >>>>>> Lew wrote:
    >>>>>>> Arne Vajh�¸j wrote:
    >>>>>>>> I would go for JSF, Hibernate, Axis2 and Richfaces. And use container
    >>>>>>>> managed security.
    >>>>>>> Also Postgres for the back end.
    >>>>>> The original poster seems to be using MySQL.
    >>>>>> Which with InnoDB tables should work fine from Java as well.
    >>>>> For restricted values of "fine".
    >>>> Maybe restricted to web sites smaller than FaceBook and Wikipedia ...
    >>>>
    >>>> But give that PostgreSQL does not run any sites of the size
    >>>> that MySQL does then it will not be the replacement.
    >>>>
    >>> It doesn't or couldn't?

    >> It doesn't.
    >>
    >> > From what I heard, PostgeSQL can hold up with
    >> > the big ones. Any source to say different?

    >>
    >> Not any technical source.
    >>
    >> Just the market.
    >>
    >> I am not aware of any really big PostgreSQL installations.
    >>

    > <http://www.postgresql.org/about/casestudies/>


    Are you seriously claiming that any of those has traffic
    in the Facebook/Wikipedia class ??

    >> It can be because all their CIO's are unaware of how good
    >> PostgreSQL is or it can be because PostgreSQL is not a good
    >> pick for the task.
    >>
    >> I consider the last a lot more likely than the first.
    >>

    > Looking at the case studies, maybe it's the first. On the other hand,
    > are they unlikely to go for MySQL? That would be a travesty (if they
    > chose MySQL over PostgreSQL).


    It may be a "travesty", but it happens all the time.

    Arne
    Arne Vajhøj, Sep 30, 2009
    #16
  17. Re: [OT] PostgreSQL was Re: Java web application frameworks / architecture

    Stefan Weiss wrote:
    > On 30/09/09 13:41, Arne Vajhøj wrote:
    >> Sabine Dinis Blochberger wrote:
    >>> Arne Vajhøj wrote:
    >>>> Sabine Dinis Blochberger wrote:
    >>>>> Arne Vajh�¸j wrote:
    >>>>>> But give that PostgreSQL does not run any sites of the size
    >>>>>> that MySQL does then it will not be the replacement.
    >>>>> From what I heard, PostgeSQL can hold up with
    >>>>> the big ones. Any source to say different?
    >>>> Not any technical source.
    >>>>
    >>>> Just the market.
    >>>>
    >>>> I am not aware of any really big PostgreSQL installations.
    >>>>
    >>> <http://www.postgresql.org/about/casestudies/>

    >> Are you seriously claiming that any of those has traffic
    >> in the Facebook/Wikipedia class ??

    >
    > There are many others who didn't publish a case report on that page.
    > Skype is using PostgreSQL, for example.


    Ah.

    So there are big users of PostgreSQL.

    Arne
    Arne Vajhøj, Sep 30, 2009
    #17
  18. Re: [OT] PostgreSQL was Re: Java web application frameworks / architecture

    Kenneth P. Turvey wrote:
    > On Wed, 30 Sep 2009 07:41:10 -0400, Arne Vajhøj wrote:
    >
    >> Sabine Dinis Blochberger wrote:
    >>> Arne Vajhøj wrote:
    >>>
    >>>> Sabine Dinis Blochberger wrote:
    >>>>> Arne Vajh�¸j wrote:
    >>>>>> Lew wrote:
    >>>>>>> Arne Vajh�¸j wrote:
    >>>>>>>> Lew wrote:
    >>>>>>>>> Arne Vajh�¸j wrote:
    >>>>>>>>>> I would go for JSF, Hibernate, Axis2 and Richfaces. And use
    >>>>>>>>>> container managed security.
    >>>>>>>>> Also Postgres for the back end.
    >>>>>>>> The original poster seems to be using MySQL. Which with InnoDB
    >>>>>>>> tables should work fine from Java as well.
    >>>>>>> For restricted values of "fine".
    >>>>>> Maybe restricted to web sites smaller than FaceBook and Wikipedia
    >>>>>> ...
    >>>>>>
    >>>>>> But give that PostgreSQL does not run any sites of the size that
    >>>>>> MySQL does then it will not be the replacement.
    >>>>>>
    >>>>> It doesn't or couldn't?
    >>>> It doesn't.
    >>>>
    >>>> > From what I heard, PostgeSQL can hold up
    >>>> > with
    >>>> > the big ones. Any source to say different?
    >>>>
    >>>> Not any technical source.
    >>>>
    >>>> Just the market.
    >>>>
    >>>> I am not aware of any really big PostgreSQL installations.
    >>>>
    >>> <http://www.postgresql.org/about/casestudies/>

    >> Are you seriously claiming that any of those has traffic in the
    >> Facebook/Wikipedia class ??
    >>
    >>>> It can be because all their CIO's are unaware of how good PostgreSQL
    >>>> is or it can be because PostgreSQL is not a good pick for the task.
    >>>>
    >>>> I consider the last a lot more likely than the first.
    >>>>
    >>> Looking at the case studies, maybe it's the first. On the other hand,
    >>> are they unlikely to go for MySQL? That would be a travesty (if they
    >>> chose MySQL over PostgreSQL).

    >> It may be a "travesty", but it happens all the time.

    >
    > I think that in the past there was a trade off between the performance of
    > MySQL and the better SQL support of PostgreSQL. The big sites chose
    > performance for obvious reasons. As I understand (and I don't know if it
    > is true or even supportable) the performance of PostgresSQL has improved
    > in recent years and the tradeoff no longer exists. PostgresSQL is just
    > as fast and has better support of SQL (subqueries and real
    > transactions).
    >
    > My information may be out of date already, and I don't have any
    > references for it, so take it for what it is.


    MySQL has supported transactions since longer back than I can remember
    (using InnoDB tables).

    MySQL has supported subqueries since 4.1 released in 2004.

    Arne
    Arne Vajhøj, Sep 30, 2009
    #18
  19. Re: [OT] PostgreSQL was Re: Java web application frameworks / architecture

    Kenneth P. Turvey wrote:
    > On Wed, 30 Sep 2009 18:06:51 -0400, Arne Vajhøj wrote:
    >> MySQL has supported transactions since longer back than I can remember
    >> (using InnoDB tables).
    >>
    >> MySQL has supported subqueries since 4.1 released in 2004.

    >
    > As I understand the support isn't as complete or bullet proof as in
    > PostgreSQL.
    >
    > I'm not really the person to be putting down MySQL though. I just don't
    > know enough about the topic to have an educated debate on it. I'm just
    > repeating what I heard for comment.


    I am not aware of any particular shortcomings in these areas.

    If I were to argue for PostgreSQL, then I would go in other
    directions.

    Arne
    Arne Vajhøj, Oct 1, 2009
    #19
  20. Lew Guest

    Re: [OT] PostgreSQL was Re: Java web application frameworks / architecture

    Sabine Dinis Blochberger wrote:
    > Yeah. And that's from where I got the impression that MySQL is not the
    > best open-source choice out there, in many cases.


    My biggest complaint with MySQL is its flouting of SQL standards. It doesn't
    support SQL TIMESTAMP, for example - it has no datetime type with subsecond
    resolution.

    While InnoDB does support foreign keys, you have to remember to use it. I was
    on a project where the developers mandated InnoDB but the ops guy mounted the
    production database as MyISAM. Oops.

    I also don't like the confusing license scheme.

    Postgres scales better for large data stores, from what I've read.

    I've a colleague who discovered through experiment that a well-tuned PG
    installation outperformed well-tuned Oracle in one real-world application with
    big-data requirements. Sure, it's a single data point, but telling,
    especially in light of what I've read.

    --
    Lew
    Lew, Oct 1, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page