Incredible! That sounds SO much like M and FileMan! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gregory Woodhouse Sent: Tuesday, May 31, 2005 6:33 AM To: hardhats-members@lists.sourceforge.net Subject: [Hardhats-members] [QueueNews] Beyond Relational Databases
I thought the cover story from the April issue of Queue (published by ACM) might be of some interest === Gregory Woodhouse [EMAIL PROTECTED] "A practical man is a man who practices the errors of his forefathers. -- Benjamin Disraeli On May 23, 2005, at 8:00 AM, [EMAIL PROTECTED] wrote: > New article on ACM Queue: > Beyond Relational Databases > http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=299 > There is more to data access than SQL. > by MARGO SELTZER, SLEEPYCAT > > >> From the Databases issue, vol. 3, no. 3 - April 2005 >> > > article excerpt: > The number and variety of computing devices in the environment are > increasing rapidly. Real computers are no longer tethered to desktops > or locked in server rooms. PDAs, highly mobile tablet and laptop > devices, palmtop computers, and mobile telephony handsets now offer > powerful platforms for the delivery of new applications and services. > These devices are, however, only the tip of the iceberg. Hidden from > sight are the many computing and network elements required to support > the infrastructure that makes ubiquitous computing possible. > > With so much computing power traveling around in briefcases and > pockets, > developers are building applications that would have been impossible > just a few years ago. Among the interesting services available today > are text and multimedia messaging, location-based search and > information services (for example, on-demand reviews of nearby > restaurants), and ad hoc multiplayer games. Over the next several > years, new classes of mobile and personalized services, impossible to > predict today, will certainly be developed. > While these > services differ from one another in major ways, they also share some > important attributes. One--the focus of this article--is the > need for data storage and retrieval functions built into the > application. Messaging applications need to move messages around the > network reliably and without loss. Location-based services need to > map > physical location to logical location (for example, GPS or cell-tower > coordinates to postal code) and then look up location-based > information. Gaming applications must record and share the current > state > of the game on distributed devices and manage content retrieval and > delivery to each of the devices in realtime. In all these cases, > fast, > reliable data storage and retrieval are critical. > > As soon as > the discussion turns to data storage and retrieval, relational > databases come to mind. Relational databases have been tremendously > successful over the past three decades, and SQL has become the lingua > franca for data access. While data management has become > almost synonymous with RDBMS, however, there are an increasing number > of applications for which lighter-weight alternatives are more > appropriate. > > In this article, we begin with a brief review of > how relational systems came to dominate the data management > landscape, > discuss how the relational technologies have evolved, present a > data-centric overview of today's emergent applications, and > delve into data management needs for today's and tomorrow's > applications. > > > RELATIONAL PREHISTORY > > Relational > databases came out of research at IBM1,2 and the University of > California at Berkeley3 in the 1970s. Relational databases were > fundamentally a reaction to the escalating costs required for > deploying and maintaining complex systems. > The key observation > was that programmers, who were very expensive, had to rewrite large > amounts of application software manually whenever the content or > physical organization of a database changed. Because the application > generally knew in detail how its data was stored, including its > on-disk layout, reorganizing databases or adding new information to > existing databases forced wholesale changes to the code accessing > those databases. > Relational databases solved this problem in two > ways. First, they hid the physical organization of the database from > the application and provided only a logical view of the data. Second, > they used a declarative language to describe the data of interest > in a > particular query, rather than forcing the programmer to write a > collection of function calls to fetch the data. These two changes > allowed programmers to describe the information they wanted and to > leave the details of optimization and access to the database > management system. This transformation relieved programmers of the > burden of rewriting application code whenever the database layout or > organization changed. > Relational databases enjoyed tremendous > success in the IT shops and data centers of the world. Businesses > with > large quantities of data to manage and sophisticated applications > using that data adopted the new technology quickly. Demand for > relational products created a market worth billions of dollars in > licensing revenue per year. Several RDBMS vendors arose in the 1980s > to compete for this lucrative business. > In the 20 years that > followed, two related trends emerged. First, the RDBMS vendors > increased functionality to provide market differentiators and to > address > each new market niche as it arose. Second, few applications need all > the features available in today's RDBMSs, so as the feature set > size increased, each application used a decreasing fraction of that > feature set. > This drive toward increasing DBMS functionality has > been accompanied by increasing complexity, and most deployments now > require a specialist, trained in database administration, to keep the > systems and applications running. Since these systems are developed > and sold as monolithic entities, even though applications may require > only a small subset of the system's functionality, each > installation pays the price of the total overall complexity. Surely, > there must be a better way. > > > THE NEW FRONTIER > > We are > not the first to notice these tides of change. In 1998, the leading > database researchers concluded that database management systems were > becoming too complex and that automated configuration and management > were becoming essential.4 Two years later, Surajit Chaudhuri and > Gerhard Weikum proposed radically rethinking database management > system architecture.5 They suggested that database management systems > be made more modular and that we broaden our thoughts about data > management to include rather simple, component-based building blocks. > Most recently, Michael Stonebraker joined the chorus, arguing that > "one size no longer fits all" and citing particular > application examples where the conventional RDBMS architecture is > inappropriate.6 > As argued by Stonebraker, the relational vendors > have been providing the illusion that an RDBMS is the answer to any > data management need. For example, as data warehousing and decision > support have emerged as important application domains, the vendors > have adapted products to address the specialized needs that arise in > these new domains. They do this by hiding fairly different data > management implementations behind the familiar SQL front end. This > model breaks down, however, as one begins to examine emerging data > needs in more depth. > Read the rest of this article at acmqueue.com > http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=299 > ------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
