Loading ...
Sorry, an error occurred while loading the content.

RE: [XP] Re: Architecture for XP and scalable web sites

Expand Messages
  • Torben Wölm
    We actually ran into that problem with the new release of our website. It was discovered that MS Transaction Server does not scale... A spike solution might
    Message 1 of 21 , Jan 2, 2001
    • 0 Attachment
      We actually ran into that problem with the new release of our website.

      It was discovered that MS Transaction Server does not scale...

      A spike solution might have helped here. Implement a simple component, put
      it into MTS and create a simple web-page that uses the component. Run the
      web stress tool on the page and look at performance...

      All COM components were reinstalled without using MTS and gave significant
      better performance.

      The lesson we learned: Use the technology you need and not the one you think
      you need. The components were not transactional, but MTS is convenient and
      it was believed that MTS is needed if you want COM components to scale...

      /Torben

      > -----Original Message-----
      > From: Laurent Bossavit [SMTP:laurent.bossavit@...]
      > Sent: Tuesday, January 02, 2001 10:37 AM
      > To: extremeprogramming@egroups.com
      > Subject: Re: [XP] Re: Architecture for XP and scalable web sites
      >
      > > The worst that can happen if the most scalable technology is
      > > selected is the project takes longer to implement and the
      > > deployment costs are slightly higher. The worst that can happen if
      > > we go for lightweight solutions is that we find the system is
      > > unusable when it eventually gets deployed. That would be bad!
      >
      > Wouldn't it be worse if you selected the most scalable technology,
      > took longer to implement the project, *and* found the system didn't
      > respond well to high loads when deployed ?
      >
      > Do you have any guarantee that won't happen ? What steps can be
      > taken to prevent this happening ?
      >
    • Jason Gruber
      Just as an addition to this COM+ on win2000 is very bad performer. We have had to re design the app because of this. Major Headache. ... From: Torben Wölm
      Message 2 of 21 , Jan 2, 2001
      • 0 Attachment
        Just as an addition to this COM+ on win2000 is very bad performer.

        We have had to re design the app because of this.

        Major Headache.

        -----Original Message-----
        From: Torben Wölm [mailto:torben.wolm@...]
        Sent: 02 January 2001 09:48
        To: 'extremeprogramming@egroups.com'
        Subject: RE: [XP] Re: Architecture for XP and scalable web sites


        We actually ran into that problem with the new release of our website.

        It was discovered that MS Transaction Server does not scale...

        A spike solution might have helped here. Implement a simple component, put
        it into MTS and create a simple web-page that uses the component. Run the
        web stress tool on the page and look at performance...

        All COM components were reinstalled without using MTS and gave significant
        better performance.

        The lesson we learned: Use the technology you need and not the one you think
        you need. The components were not transactional, but MTS is convenient and
        it was believed that MTS is needed if you want COM components to scale...

        /Torben

        > -----Original Message-----
        > From: Laurent Bossavit [SMTP:laurent.bossavit@...]
        > Sent: Tuesday, January 02, 2001 10:37 AM
        > To: extremeprogramming@egroups.com
        > Subject: Re: [XP] Re: Architecture for XP and scalable web sites
        >
        > > The worst that can happen if the most scalable technology is
        > > selected is the project takes longer to implement and the
        > > deployment costs are slightly higher. The worst that can happen if
        > > we go for lightweight solutions is that we find the system is
        > > unusable when it eventually gets deployed. That would be bad!
        >
        > Wouldn't it be worse if you selected the most scalable technology,
        > took longer to implement the project, *and* found the system didn't
        > respond well to high loads when deployed ?
        >
        > Do you have any guarantee that won't happen ? What steps can be
        > taken to prevent this happening ?
        >

        To Post a message, send it to: extremeprogramming@...

        To Unsubscribe, send a blank message to:
        extremeprogramming-unsubscribe@...

        Ad-free courtesy of objectmentor.com
      • Jason Gruber
        But win2000 does cluster well. Especially with SQL2000 ... From: Jason Gruber [mailto:jason.gruber@itcnet.co.uk] Sent: 02 January 2001 11:18 To:
        Message 3 of 21 , Jan 2, 2001
        • 0 Attachment
          But win2000 does cluster well. Especially with SQL2000

          -----Original Message-----
          From: Jason Gruber [mailto:jason.gruber@...]
          Sent: 02 January 2001 11:18
          To: 'extremeprogramming@egroups.com'
          Subject: RE: [XP] Re: Architecture for XP and scalable web sites


          Just as an addition to this COM+ on win2000 is very bad performer.

          We have had to re design the app because of this.

          Major Headache.

          -----Original Message-----
          From: Torben Wölm [mailto:torben.wolm@...]
          Sent: 02 January 2001 09:48
          To: 'extremeprogramming@egroups.com'
          Subject: RE: [XP] Re: Architecture for XP and scalable web sites


          We actually ran into that problem with the new release of our website.

          It was discovered that MS Transaction Server does not scale...

          A spike solution might have helped here. Implement a simple component, put
          it into MTS and create a simple web-page that uses the component. Run the
          web stress tool on the page and look at performance...

          All COM components were reinstalled without using MTS and gave significant
          better performance.

          The lesson we learned: Use the technology you need and not the one you think
          you need. The components were not transactional, but MTS is convenient and
          it was believed that MTS is needed if you want COM components to scale...

          /Torben

          > -----Original Message-----
          > From: Laurent Bossavit [SMTP:laurent.bossavit@...]
          > Sent: Tuesday, January 02, 2001 10:37 AM
          > To: extremeprogramming@egroups.com
          > Subject: Re: [XP] Re: Architecture for XP and scalable web sites
          >
          > > The worst that can happen if the most scalable technology is
          > > selected is the project takes longer to implement and the
          > > deployment costs are slightly higher. The worst that can happen if
          > > we go for lightweight solutions is that we find the system is
          > > unusable when it eventually gets deployed. That would be bad!
          >
          > Wouldn't it be worse if you selected the most scalable technology,
          > took longer to implement the project, *and* found the system didn't
          > respond well to high loads when deployed ?
          >
          > Do you have any guarantee that won't happen ? What steps can be
          > taken to prevent this happening ?
          >

          To Post a message, send it to: extremeprogramming@...

          To Unsubscribe, send a blank message to:
          extremeprogramming-unsubscribe@...

          Ad-free courtesy of objectmentor.com

          To Post a message, send it to: extremeprogramming@...

          To Unsubscribe, send a blank message to:
          extremeprogramming-unsubscribe@...

          Ad-free courtesy of objectmentor.com
        • robert.claeson@brightinteractive.com
          ... BMP (Bean Managed Persistence) entity beans aren t bad, but I d hesitate to recommend anybody to use CMP (Container Managed Persistence) entity beans for
          Message 4 of 21 , Jan 2, 2001
          • 0 Attachment
            John Brewer:

            >I've heard of at least one XP project that ended up removing the
            >entity beans from their system because of performance problems.

            BMP (Bean Managed Persistence) entity beans aren't bad, but I'd hesitate
            to recommend anybody to use CMP (Container Managed Persistence) entity
            beans for anything but the simplest applications.

            >Fortunately, they had the well-factored code and corresponding tests
            >to make that possible. I believe they eventually eliminated all the
            >fancy app-server stuff from their code, allowing them to deploy using
            >an inexpensive servlet container.

            Using an app server certainly helps for load balancing of application
            code, but a simple RMI server is often easier and faster than using an EJB
            container.

            /Robert
          • robert.claeson@brightinteractive.com
            ... I ve never liked WebLogic all that much. We use IBM s WebSphere. Combined with the VA Java Enterprise (Smalltalk-like) development environment with
            Message 5 of 21 , Jan 2, 2001
            • 0 Attachment
              Keith Richardson:

              >There have been several messages in this forum describing situations
              >where EJB was found to be overkill and unnecessary. I am worried that
              >selecting another technology could leave me doing major rework
              >against a deployment deadline when I run in to the eventual
              >performance bottleneck. What success have other Web developers had in
              >passing performance limits?

              I've never liked WebLogic all that much. We use IBM's WebSphere. Combined
              with the VA Java Enterprise (Smalltalk-like) development environment with
              built-in debugging of servlets and JSP's and distributed debuging, we're
              quite productive. WebSphere uses golbs of memory. 512 MB is a minimum for
              simpler deployment under Windows, and 1GB is the recommendation for
              small-scale deployment under UNIX. More memory is preferable. Other than
              that, and by avoiding to use CMP entity beans, it scales well. Oh, and use
              the 3.5 version. The older versions (even 3.02) will give you gray hair
              when you try to install it.

              /Robert
            • John Brewer
              ... tests ... the ... using ... application ... an EJB ... They weren t even using RMI. They just ran servlets and JDBC connections all in the same VM. John
              Message 6 of 21 , Jan 2, 2001
              • 0 Attachment
                --- In extremeprogramming@egroups.com, robert.claeson@b... wrote:
                > John Brewer:
                > >Fortunately, they had the well-factored code and corresponding
                tests
                > >to make that possible. I believe they eventually eliminated all
                the
                > >fancy app-server stuff from their code, allowing them to deploy
                using
                > >an inexpensive servlet container.
                >
                > Using an app server certainly helps for load balancing of
                application
                > code, but a simple RMI server is often easier and faster than using
                an EJB
                > container.

                They weren't even using RMI. They just ran servlets and JDBC
                connections all in the same VM.

                John Brewer
                Jera Design
              • David Corbin
                ... My problem here, is that I think to reasonably spike this, I d spend the better part of a week (minimum). Elsewhere, people have said spike s shouldn t be
                Message 7 of 21 , Jan 2, 2001
                • 0 Attachment
                  Chad Fowler wrote:
                  >
                  > Perhaps, your project doesn't fall into the "in most cases"
                  > category. If it were me, I would choose the simplest thing that I
                  > *believe* could possibly work and follow up with a performance spike
                  > using load testing software. Of course, as Ron mentioned in a
                  > previous response, words like


                  My problem here, is that I think to reasonably spike this, I'd spend the
                  better
                  part of a week (minimum). Elsewhere, people have said spike's shouldn't
                  be that long.
                  I still think it would be time well spent though....

                  >
                  > To Post a message, send it to: extremeprogramming@...
                  >
                  > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                  >
                  > Ad-free courtesy of objectmentor.com

                  --
                  David Corbin
                  Mach Turtle Technologies, Inc.
                  http://www.machturtle.com
                  dcorbin@...
                • John Brewer
                  ... the ... shouldn t ... If scalability is really a major concern of business , they ll probably be more than willing to schedule a week early on to reduce
                  Message 8 of 21 , Jan 2, 2001
                  • 0 Attachment
                    --- In extremeprogramming@egroups.com, David Corbin <dcorbin@m...>
                    wrote:

                    > My problem here, is that I think to reasonably spike this, I'd spend
                    the
                    > better
                    > part of a week (minimum). Elsewhere, people have said spike's
                    shouldn't
                    > be that long.
                    > I still think it would be time well spent though....

                    If scalability is really a major concern of business', they'll
                    probably be more than willing to schedule a week early on to reduce
                    those concerns.

                    Be sure that, as development, you push back on business as to what
                    they mean by "scalable" -- how many hits per day, hour, second do they
                    need. If they can't answer, they need to go back to their customers
                    and figure out some real numbers. Once you have those numbers, you
                    just need the simplest solution that meets them.

                    John Brewer
                    Jera Design
                  • Anders Bengtsson
                    robert.claeson@brightinteractive.com wrote:BMP (Bean Managed Persistence) entity beans aren t bad, but I d hesitate to recommend anybody to use CMP
                    Message 9 of 21 , Jan 2, 2001
                    • 0 Attachment
                      robert.claeson@... wrote:

                      > BMP (Bean Managed Persistence) entity beans aren't bad, but I'd hesitate
                      > to recommend anybody to use CMP (Container Managed Persistence) entity
                      > beans for anything but the simplest applications.

                      But why would you want your application to be anything but the simplest?
                      ;)
                      For us, using CMP meant that the app server could use its object cache.
                      This enabled very high performance, and a very low load on the SQL
                      server.

                      > Using an app server certainly helps for load balancing of application
                      > code, but a simple RMI server is often easier and faster than using an EJB
                      > container.

                      That's true (assuming you have an RMI server that optimizes calls within
                      the same JVM).
                      One of the big reasons for using J2EE in the first place for us was the
                      load balancing. So far the application has never needed any load
                      balancing, since it performed well without it, even on small hardware.
                      If only we had realised that "you aren't gonna need it". But it's just
                      so easy to get carried away in the scalability hype... ;)

                      /Anders
                      _____________________________________________________________________
                      A n d e r s B e n g t s s o n ndrsbngtssn@...
                      Stockholm, Sweden

                      _____________________________________________________
                      Do You Yahoo!?
                      S�lj eller l�gg ett bud p� Yahoo! Auktioner http://se.auctions.yahoo.com
                    • Dinwiddie, George
                      Keith, Maybe you need to restructure your user story to specify an expected load level and possibly state something like must continue to operate at a load
                      Message 10 of 21 , Jan 2, 2001
                      • 0 Attachment
                        Keith,

                        Maybe you need to restructure your user story to specify an expected
                        load level and possibly state something like "must continue to operate
                        at a load level X times the expected load level." It seems to me that
                        you can't measure performance under load without *some* estimate of
                        what "high load" means. I think what you're really getting at is that
                        you don't want a steep knee to the function; you don't want things to
                        just die when you go beyond the designed load limit. Therefore,
                        accept that your performance beyond that point will probably be
                        degraded and just check that you can degrade somewhat gracefully.
                        This is something you can test.

                        - George

                        -----Original Message-----
                        From: Keith Richardson [mailto:keith@...]

                        How would you have handled the user story: "Must be able to scale
                        quickly to unpredictable levels when a new client wants to deploy in
                        a high load environment"? Maybe there is a good reason by this is a
                        bad user story but I am having a hard time not having this need lead
                        to a technology selection.
                        Keith Richardson
                      • robert.claeson@brightinteractive.com
                        ... That also works, of course. It s just that in most of our applications, the database quickly becomes the bottleneck, so we tend to often keep all or most
                        Message 11 of 21 , Jan 2, 2001
                        • 0 Attachment
                          Me:

                          > Using an app server certainly helps for load balancing of
                          > application code, but a simple RMI server is often easier
                          > and faster than using an EJB container.

                          John Brewer:

                          >They weren't even using RMI. They just ran servlets and JDBC
                          >connections all in the same VM.


                          That also works, of course. It's just that in most of our applications,
                          the database quickly becomes the bottleneck, so we tend to often keep all
                          or most active data in memory, and it needs to be shared between VM's. We
                          often do that by using a distributed command pattern and an RMI-based
                          server. RMI just because it's easy to do.

                          /Robert
                        • robert.claeson@brightinteractive.com
                          ... The requirements for many of the applications that we develop often causes the database schema to become quite complicated, on the order of several hundred
                          Message 12 of 21 , Jan 2, 2001
                          • 0 Attachment
                            Me:

                            > BMP (Bean Managed Persistence) entity beans aren't bad, but I'd hesitate
                            > to recommend anybody to use CMP (Container Managed Persistence) entity
                            > beans for anything but the simplest applications.

                            Anders Bengtsson:

                            >But why would you want your application to be anything but the simplest?

                            The requirements for many of the applications that we develop often causes
                            the database schema to become quite complicated, on the order of several
                            hundred tables. Most database queries target multiple tables. CMP usually
                            just plain doesn't work satisfactorily under those conditions. If youonly
                            need to access one or two tables, then fine, go ahead and use CMP. That's
                            an utterly simple access, though.

                            >For us, using CMP meant that the app server could use its object cache.
                            >This enabled very high performance, and a very low load on the SQL
                            >server.

                            We've had problems with that kind of caching. It works as long as all
                            accesses pass through the CMP layer. If there are also other applications
                            updating the same tables, the object cache doesn't pick up the database
                            changes. Also, if there are many references involved, the CMP layer often
                            seems to have problems with that, causing accesses through the object
                            cache to become slower than direct database accesses.

                            I'm mostly refering to WebSphere here, but TopLink and WebLogic shows
                            similar performance profiles. There's also a product named "Object
                            Extender" for VA Smalltalk that's the predecessor to the CMP stuff in
                            WebSphere and VA Java. We've had tons of problems with that as well,
                            especially if persistent objects inherit from each other.

                            Me:

                            > Using an app server certainly helps for load balancing of application
                            > code, but a simple RMI server is often easier and faster than using an
                            EJB
                            > container.

                            Anders Bengtsson:

                            >That's true (assuming you have an RMI server that optimizes calls within
                            >the same JVM).

                            I'm referring to the case where there are multiple servlet containers
                            accessing a shared RMI server through a network connection.

                            >One of the big reasons for using J2EE in the first place for us was the
                            >load balancing. So far the application has never needed any load
                            >balancing, since it performed well without it, even on small hardware.
                            >If only we had realised that "you aren't gonna need it". But it's just
                            >so easy to get carried away in the scalability hype... ;)

                            Fact is, getting acquainted with a good application server and using it
                            for both small and large applications helps both quality and productivity.
                            In this case, there are good reasons for not paying too much attention to
                            YAGNI. Too many web sites has been developed too "small", and has been
                            facing tremendeous performance problems when the load increases. YDKIYGNI
                            ("You Don't Know If You're Gonna Need It").

                            Peace, and all that stuff.

                            /Robert
                          • Ron Jeffries
                            At 05:27 PM 1/2/2001 +0100, it seemed like ... This makes me wonder whether you really wish you had an object database instead of relational. Can you tell us a
                            Message 13 of 21 , Jan 2, 2001
                            • 0 Attachment
                              At 05:27 PM 1/2/2001 +0100, it seemed like
                              robert.claeson@... wrote:
                              >The requirements for many of the applications that we develop often causes
                              >the database schema to become quite complicated, on the order of several
                              >hundred tables. Most database queries target multiple tables. CMP usually
                              >just plain doesn't work satisfactorily under those conditions. If youonly
                              >need to access one or two tables, then fine, go ahead and use CMP. That's
                              >an utterly simple access, though.

                              This makes me wonder whether you really wish you had an object database
                              instead of relational. Can you tell us a little about what kind of app
                              wants hundreds of tables and lots of multiple-table queries?

                              Thanks!

                              Ronald E Jeffries
                              http://www.XProgramming.com
                              http://www.objectmentor.com
                            • Anders Bengtsson
                              On Tue, 2 Jan 2001 robert.claeson@brightinteractive.com wrote:But why would you want your application to be anything but the simplest? The
                              Message 14 of 21 , Jan 2, 2001
                              • 0 Attachment
                                On Tue, 2 Jan 2001 robert.claeson@... wrote:

                                > >But why would you want your application to be anything but the simplest?
                                >
                                > The requirements for many of the applications that we develop often causes
                                > the database schema to become quite complicated, on the order of several
                                > hundred tables. Most database queries target multiple tables. CMP usually
                                > just plain doesn't work satisfactorily under those conditions. If youonly
                                > need to access one or two tables, then fine, go ahead and use CMP. That's
                                > an utterly simple access, though.

                                We had just over 30 tables, with mostly one-way relations between them.
                                There were, as you say, problems in the few cases where there were many
                                tables involved.

                                > I'm mostly refering to WebSphere here, but TopLink and WebLogic shows
                                > similar performance profiles. There's also a product named "Object
                                > Extender" for VA Smalltalk that's the predecessor to the CMP stuff in
                                > WebSphere and VA Java. We've had tons of problems with that as well,
                                > especially if persistent objects inherit from each other.

                                I've heard bad things beeing said about the entity bean performance of
                                WebSphere, but one of their architechts told me that they in fact had
                                good performance. :-)

                                > >That's true (assuming you have an RMI server that optimizes calls within
                                > >the same JVM).
                                >
                                > I'm referring to the case where there are multiple servlet containers
                                > accessing a shared RMI server through a network connection.

                                If your app is really fast, compared to the load, its really nice to be
                                able to run it all in a single JVM. Both the speed of running it all
                                in one JVM and the comfort of knowing that you can buy yourself out of
                                performance problems.

                                > Fact is, getting acquainted with a good application server and using it
                                > for both small and large applications helps both quality and productivity.
                                > In this case, there are good reasons for not paying too much attention to
                                > YAGNI. Too many web sites has been developed too "small", and has been
                                > facing tremendeous performance problems when the load increases. YDKIYGNI
                                > ("You Don't Know If You're Gonna Need It").

                                This turns out to the biggest problem of all in building web applications,
                                for me at least. You never really know how "big" your solution needs to
                                be, and that single decision affects the entire project greatly.
                                I guess the true XP way would be to adopt it as you go, to avoid that kind
                                of decision. Some day I'll have that kind of courage. :)
                                In the meantime I'll take your advice and find out the ins and outs of my
                                app server.

                                /Anders
                                _____________________________________________________________________
                                A n d e r s B e n g t s s o n ndrsbngtssn@...
                                Stockholm, Sweden


                                _________________________________________________________
                                Do You Yahoo!?
                                Get your free @... address at http://mail.yahoo.com
                              • Anders Bengtsson
                                On Tue, 2 Jan 2001, Ron Jeffries wrote:This makes me wonder whether you really wish you had an object database instead of relational. Can you tell us a
                                Message 15 of 21 , Jan 2, 2001
                                • 0 Attachment
                                  On Tue, 2 Jan 2001, Ron Jeffries wrote:

                                  > This makes me wonder whether you really wish you had an object database
                                  > instead of relational. Can you tell us a little about what kind of app
                                  > wants hundreds of tables and lots of multiple-table queries?

                                  Who _don't_ wish that they had an object database? I've been wishing
                                  that for years! ;-)

                                  _____________________________________________________________________
                                  A n d e r s B e n g t s s o n ndrsbngtssn@...
                                  Stockholm, Sweden


                                  _________________________________________________________
                                  Do You Yahoo!?
                                  Get your free @... address at http://mail.yahoo.com
                                • robert.claeson@brightinteractive.com
                                  ... causes ... You bet. I ve always wished that. However, there was none reasonably priced object database that had all the other features that we needed.
                                  Message 16 of 21 , Jan 2, 2001
                                  • 0 Attachment
                                    Me:

                                    >The requirements for many of the applications that we develop often
                                    causes
                                    >the database schema to become quite complicated, on the order of several
                                    >hundred tables. Most database queries target multiple tables. CMP usually
                                    >just plain doesn't work satisfactorily under those conditions. If youonly
                                    >need to access one or two tables, then fine, go ahead and use CMP. That's
                                    >an utterly simple access, though.

                                    Ron Jeffries:

                                    >This makes me wonder whether you really wish you had an object database
                                    >instead of relational.

                                    You bet. I've always wished that. However, there was none reasonably
                                    priced object database that had all the other features that we needed.
                                    Nowadays, I try to find ways to use Oracle 8i or DB2 as much as possible.
                                    They have reasonably object-oriented features to make the mapping easier.

                                    >Can you tell us a little about what kind of app
                                    >wants hundreds of tables and lots of multiple-table queries?

                                    It's actually a quite boring application. It's an administrative
                                    application for member organizations. It manages various levels of
                                    membership, functions within the organization that members may have, local
                                    chapters, benefits, invoicing, accounts receivables, insurance policies,
                                    subscriptions and what not. All in all a pretty complete package for what
                                    many member organizations need. Most aspects are configurable. The first
                                    version was, incidentally, written in Smalltalk. It has since been
                                    rewritten in Java for various reasons.

                                    The invoicing run is, well, complicated. It took almost a day to run when
                                    we had implemented it using VisualAge's persistence stuff. We then tried
                                    to rewrite it using TopLink, which didn't improve things much. We finally
                                    ended up rewriting it as Oracle stored procedures in PL/SQL (mind you, we
                                    didn't have much prior experience from PL/SQL), which decreased the
                                    execution time to 1 minute and 58 seconds using the same data set (~1 GB
                                    of invoice detail data). It took two people just two days to do that
                                    rewrite, including debugging, which I guess shows the effectiveness of
                                    pair programming for solving problems like these.

                                    /Robert
                                  • C. Keith Ray
                                    [...] ... [...] For $699 you can try a spike with WebObjects.
                                    Message 17 of 21 , Jan 2, 2001
                                    • 0 Attachment
                                      [...]
                                      > The clear consensus is to keep the technology simple. Now to pick a
                                      > robust and simple technology that works well with XP. Java is a much
                                      > cleaner environment than ActiveX which would suggest not using MS-
                                      > based development environment for IIS. A new question: what
                                      > combination of development tools and deployment environment is best
                                      > for a Web application built using XP? It should have a clean object
                                      > model and a build environment that allows for rapid development cycle
                                      > times. It must also be robust and a good performer because I don't
                                      > want to be kludging around limitations or speed bottlenecks. What is
                                      > being used for XP and how is it working?
                                      > Keith Richardson
                                      [...]

                                      For $699 you can try a spike with WebObjects.
                                      <http://www.apple.com/webobjects/techspecs.html>
                                    • Patrick Logan
                                      ... There are fairly simple star schemas published for these kinds of applications. Star schemas are a good fit for relational databases, are easy to
                                      Message 18 of 21 , Jan 3, 2001
                                      • 0 Attachment
                                        --- robert.claeson@b... wrote:
                                        >
                                        > It's actually a quite boring application. It's an administrative
                                        > application for member organizations...
                                        > chapters, benefits, invoicing, accounts receivables,
                                        > insurance policies, subscriptions and what not...

                                        There are fairly simple star schemas published for these kinds
                                        of applications. Star schemas are a good fit for relational
                                        databases, are easy to understand, and happen to map well into
                                        object designs. Look for books by Kimble and/or Adamson &
                                        Venerable.

                                        > ...It took almost a day to run when
                                        > we had implemented it using VisualAge's persistence stuff.
                                        > ...using TopLink, which didn't improve things much. We finally
                                        > ended up rewriting it as Oracle stored procedures...
                                        > It took two people just two days to do that
                                        > rewrite, including debugging, which I guess shows the
                                        > effectiveness of pair programming...

                                        Frankly, I think it also shows how many problems do not need
                                        O/R mapping tools or an OODBMS.
                                      • Patrick Logan
                                        ... There are some practices that can simplify these schema, and so help you move faster in your XP project. One is not to use NULL in the database. Instead
                                        Message 19 of 21 , Jan 3, 2001
                                        • 0 Attachment
                                          --- Anders Bengtsson <ndrsbngtssn@y...> wrote:

                                          > We had just over 30 tables, with mostly one-way relations
                                          > between them. There were, as you say, problems in the few
                                          > cases where there were many tables involved.

                                          There are some practices that can simplify these schema, and
                                          so help you move faster in your XP project.

                                          One is not to use NULL in the database. Instead have a row
                                          that represents the "null". If not all organizations have
                                          a related whatsit, then instead of having their whatsit
                                          column be NULL, have the whatsit column refer to a row in
                                          the whatsit column that represents the "no whatsit" whatsit.

                                          This is kind of like the Null Object pattern. (See Ward
                                          Cunningham's Checks pattern language at www.c2.com)

                                          Even better is to use this "null row" pattern along with
                                          the star schema pattern (same web site as Checks).

                                          The star schema pattern simpifies the relationships between
                                          tables, making the schema easier to understand, more
                                          "object/relational friendly", better performing, more
                                          maintainable, and less prone to mistakes.

                                          All good for XP projects.
                                        • Anders Bengtsson
                                          On Wed, 3 Jan 2001, Patrick Logan wrote:One is not to use NULL in the database. Instead have a row that represents the null . If not all organizations
                                          Message 20 of 21 , Jan 4, 2001
                                          • 0 Attachment
                                            On Wed, 3 Jan 2001, Patrick Logan wrote:

                                            > One is not to use NULL in the database. Instead have a row
                                            > that represents the "null". If not all organizations have
                                            > a related whatsit, then instead of having their whatsit
                                            > column be NULL, have the whatsit column refer to a row in
                                            > the whatsit column that represents the "no whatsit" whatsit.
                                            >
                                            > This is kind of like the Null Object pattern. (See Ward
                                            > Cunningham's Checks pattern language at www.c2.com)

                                            That's interesting, I've never thought about using Null Object for
                                            databases, even though I've used it in other contexts.

                                            > Even better is to use this "null row" pattern along with
                                            > the star schema pattern (same web site as Checks).
                                            >
                                            > The star schema pattern simpifies the relationships between
                                            > tables, making the schema easier to understand, more
                                            > "object/relational friendly", better performing, more
                                            > maintainable, and less prone to mistakes.

                                            The schema we used initially was simply whatever the automated persistence
                                            of our EJB server chose to store the beans as. It actually worked great in
                                            most cases, but I guess it was kind of asking for trouble, since it meant
                                            that we didn't really spend any time thinking about schema design.
                                            On the other hand, there weren't really many problems with it, so in the
                                            end I guess it did actually save time.
                                            So, even "TSTTCPW by accident" works some times. :)

                                            /Anders
                                            _____________________________________________________________________
                                            A n d e r s B e n g t s s o n ndrsbngtssn@...
                                            Stockholm, Sweden


                                            _________________________________________________________
                                            Do You Yahoo!?
                                            Get your free @... address at http://mail.yahoo.com
                                          Your message has been successfully submitted and would be delivered to recipients shortly.