Changes
→Integration
<blockquote>Does Symphony actually use Oracle as a relational database, or as a glorified file system for buzzword compliance?</blockquote>
<blockquote> Unicorn originally used an ISAM flat-file database. Unicorn/Symphony customers have the option of using Oracle instead, if they would prefer that. My understanding is that the ISAM flat-file structure was ported verbatim to Oracle, so makes little (or no?) use of relationships, normalization, referential integrity or triggers to maintain consistency. </blockquote>
:: Perhaps ironically, Horizon actually DOES have a fairly well normalized sensical relational database structure. Horizon has been cancelled, Unicorn/Symphony has been continued instead, with it's apparent flat-file-ish schema. Horizon's reasonably normalized schema does make it fairly easy to 'hack' additional features on, compared to the typical proprietary ILS.
==Community-driven==
==Scalability==
Some open source system vendors describe their software as "consortially aware" or having been built for consortia from the ground up. This is fairly weaselly language.
<blockquote> ...said the pot to the kettle </blockquote> <blockquote> Yes, this software can be `consortially aware' without any of the attendant performance (One didn't even support the Z39.50 international ISO standard until recently!) Having been designed for a single consortium such as PINES, does not guarantee that the software will work for another consortia's needs, particularly with the diversity of needs and variety of system architectures that exist in a fully dimensional marketplace. </blockquote> <blockquote>"The shortcomings of proprietary systems are pretty much the same across all vendors, and the biggest shortcoming is in “multiness†- the number of sets of rules you can use." -- http://www.swissarmylibrarian.net/2009/10/29/ma-open-source-info-session-notes</blockquote>
<blockquote> Using a 2Mb broadband connection, IE8 and HTTPWatch to measure the reponse time to the nearest millisecond, a sample search for "Germany" on a SirsiDynix SaaS hosted instance of "Enterprise" for a US public library took 7.231 seconds to load the core content of the page (i.e. main HTML, clickable search results and facets). Cover scans fully loaded after 16.352 seconds. The final HTTP request was completed at 64.611 seconds. From a users point of view, the page was usable & browseable after 7 seconds. Many factors may have affected this sample test, but it was far from "sub-second". The test was performed on a Sunday morning, so it is doubtful that the SaaS server was under load at the time. Subsequent searches completed more quickly (averaging 3.724 seconds for the page to be usable), which indicates the SaaS implementation relies on the caching of the page's JavaScript elements to achieve optimum performance (n.b. this is not a critism!). A visual inspection of the HTML shows that the developers have not chosen to optimize the HTML (e.g. large sections of unneccessary whitespace take up around 45% of the HTML). </blockquote>
==Speed==
