Data Access Manager
Data Access Manager (DAM) var ett databasåtkomst - API för det klassiska Mac OS , som introducerades 1991 som en tillägg till System 7 . Liknande i koncept som ODBC , såg DAM liten användning och lades så småningom ner i slutet av 1990-talet. Endast en handfull produkter har någonsin använt det, även om det användes för några extremt imponerande demoware i början av 1990-talet. Modernare versioner av det klassiska Mac OS och macOS använder ODBC för den här rollen istället.
Begrepp
DAM och ODBC är lika på många sätt. Det primära syftet med båda systemen var att skicka "frågesträngar" till en dataleverantör, som skulle svara (potentiellt) med en "resultatuppsättning" bestående av rader med data. Båda systemen förväntades konvertera data till och från systemets respektive format, heltal och strängar till exempel. Dessutom tillhandahöll båda ett kommunikationsundersystem som gömde detaljerna för att skicka frågor och data mellan klienten och servern.
Liksom de flesta Apple-program, försökte DAM göra frågeprocessen så enkel som möjligt för användarna, både applikationsanvändare och programmerare som skrev dessa applikationer. En särskilt anmärkningsvärd egenskap var konceptet "förfrågningsdokument". Frågedokument innehöll valfritt antal fördefinierade frågor (eller andra serverkommandon), tillsammans med valfri kod för att ändra dem innan de skickades till servern. Till exempel kan ett typiskt frågedokument innehålla en frågesträng som skulle logga in på databasservern, och om det lyckades, slå upp det aktuella datumet från den lokala klientdatorn med ett Mac OS-anrop och använd sedan det datumet i en fråga som returnerar lager i ett lager för ett givet datum. Frågedokument kan också innehålla datorkod och resurser som behövs för att stödja denna process, till exempel en dialogruta som frågar efter användarnamn och lösenord.
Applikationer kan använda frågedokument utan att ha någon aning om frågans inre delar. De öppnade helt enkelt dokumentet, som bestod av en serie resurser , och körde varje frågeresurs inuti i tur och ordning. DAM skulle säkerställa att all nödvändig kod i dokumentet körs utan att applikationen ens var medveten om det, och så småningom skulle resultaten skickas tillbaka till applikationen för visning. Hela operationen var ogenomskinlig, vilket gjorde det möjligt för applikationer att lägga till DAM-stöd med lätthet.
DAM inkluderade även ytterligare två direkta API:er, High Level-gränssnittet och Low Level-gränssnittet. High Level var ganska likt att använda frågedokument, även om det förväntades att programmet skulle konstruera frågorna i kod snarare än resurser. Högnivågränssnittet liknar i stort sett ODBC:s publika gränssnitt. Låg nivå gjorde det möjligt för programmeraren att ingripa när som helst i frågeprocessen, till exempel hämta data rad för rad.
En stor skillnad mellan DAM och ODBC kom till stor del av en slump. Före utvecklingen av DAM hade Apple köpt en databasmellanprogramprodukt som de sålde som Data Access Language eller DAL. DAL var i huvudsak en standardiserad SQL med översättare för olika databaser som kördes på serversidan. Standarder för SQL var extremt grundläggande på den tiden, och relativt dåligt stödda, DAL åtgärdade detta genom att ha ett enda språk och konvertera till och från de andra systemen. Klientmjukvara, inklusive DAM, kunde skicka frågor på DAL:s standardspråk som sedan skulle översättas och exekveras oavsett back-end-databasen.
Däremot utvecklades ODBC från början till att vara ett SQL-baserat system, baserat på det standardiserade Call-Level Interface från X/Open (nu en del av Open Group ). Under OBDC gjordes varje datakälla för att se ut som en SQL-server. För serverlösa källor, som textfiler, skulle en lokal SQL-parser tolka kommandona och läsa filen. Under ODBC förväntas alla datakällsdrivrutiner förstå SQL och översätta den till den lokala dialekten vid behov, samt konvertera data till standardformat när den returneras.
Denna skillnad gjorde DAM mycket mindre användbar än ODBC i praktiken. Eftersom det förväntades att DAL skulle tillhandahålla frågestandardisering, hade DAM inget lager liknande ODBC:s för att översätta olika dialekter. För att DAM verkligen skulle vara användbart var användaren också tvungen att köpa och installera en DAL-server för just sin databas. DAL var allmänt känt för att vara långsamt och dyrt, vilket allvarligt försämrade DAM:s totala värde. Vidare standardiserade DAM inte språket för åtkomst av icke-SQL-datakällor; en adapter för en textfil kan använda ett icke-SQL-språk, eller ett helt funktionsanropsbaserat system istället. Inte heller ingick några enkla gränssnitt för textfiler eller liknande datakällor med grundläggande DAM-installationer.
Används
En av de största kunderna för DAM var HyperCard , Apples datahanterare/ snabbapplikationsutvecklingssystem . Att kombinera HyperCards utmärkta formulärsystem med data från DAM resulterade i något som ingen någonsin sett tidigare datadrivna GUI-appar. Den vanligaste demon av systemet visade en HyperCard-stack som frågade efter en serie Baskin-Robbins- databaser, tidigare omöjligt eftersom varje regionalt område använde sina egna databasservrar som DAL nu kombinerade till en. Återbeställningar för mer lager kan göras genom att dra en serie glasskulor på en grafisk visning av det aktuella lagret.
Systemet var så imponerande att det fick andra databasleverantörer att kämpa för att tillhandahålla liknande system; Oracle Corporation köpte omedelbart PLUS från Spinnaker Software och släppte det först som Oracle Card och sedan Oracle Media Objects . Andra företag följde liknande vägar, och snart var det händelsedrivna databasgränssnittet en standardfunktion i de flesta system.
Ett antal andra applikationer använde också systemet, kanske ironiskt nog Microsofts olika Office-produkter gör det med största regelbundenhet. Annat än det var DAM-stöd ganska sällsynt, och produkten såg inte utbredd användning. Kanske berodde mycket av detta på den ofullständiga karaktären hos DAM-systemet som helhet ; behovet av DAL-mellanprogramvara i de flesta fall och avsaknaden av billiga frågedokumentbyggare (det fanns några dyra) gjorde omkostnaden för att använda DAM ganska hög.
Mac OS X släpptes . En "klassisk" Mac OS-version av ODBC var tillgänglig under en tid, även om stödet var begränsat. Från och med lanseringen av OS X 10.2 Jaguar började Apple distribuera en version av iODBC plattformsoberoende ODBC-drivrutiner. Från och med OS X 10.4 Tiger har Apple introducerat ett nytt och mycket "högre nivå"-system känt som Core Data . Med Core Data kan utvecklare serialisera data till SQLite för bearbetning, liknande koncept som ODBC när de används med en icke-SQL-datakälla.