If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#10
|
|||
|
|||
Might be outgrowing Access but daunted by SQL Server
"Banana" Banana@Republic wrote in message news:4B8B14B3.7010008@Republic... david wrote: Banana, Access/Jet is built on top of the Windows Database primatives. But what exactly is a 'Windows Database primitives'? I've googled this phrase and didn't find anything useful. I'd like to know what you mean by that phrase. Well, since you ask... It's like Windows explorer: you never stop to think how it works any more. But once upon a time, Word Processing was done on Typewriters, Layout was done on TypeSetters, and databases were the main reason why commercial computer systems existed. Even Unix, which in its academic version had no database system, had built-in database primitives in the version most used inside Bell. People bought DOS computers and used them for database systems: the OS primitives which supported this are the Windows Database Primitives. DOS had only the most basic database service: read/write/flush record, and file folders, which were then called directories. The file folder is the 'Database' unit of DOS-based database systems. The next important step was the addition of SHARE.EXE, which added record locking to the file system. Windows 3.x added a File API which was a thin cover for the DOS file system, including GET,SET,LOCK, UNLOCK and file folders. The next important step was the addition of the Network Redirector, which was the part of the Network Client which re-directed File System commands to a Network Server. The API has changed from Win16 to Win32 to WinNT, but it has remained backward-compatible to DOS through the whole change. The data storage system has changed underneath, but the API has remained backward-compatible. The Database Primitives than WinXP offers and that are re-directed to the Server, are still the same database primitives that DOS offered with SHARE. Create Record. Read Record, Update Record. Delete Record. Lock Record. Unlock Record. Missing is FLUSH (required for persistence), indexing, and transactions. Novell Netware had the missing three: transactions have finally been added to Windows, but are not yet used by JET or ACE. 'CRUD' is the basis of all database systems, not just Relational Database Systems. Create Record, Read-Record, Write-Record, Lock-Record, Flush, and File Folders were the basis of all DOS database systems, the systems which were replaced by Access and SQL Server. Access was built on top of the OS database primitives, as were all previous DOS database system. It differed by including everything inside one file (as SQL Server does). The code was stored in records in the database. The queries were stored in records in the database. The relationships (that is, the table definitions) were stored in records in the database. And the only way to manipulate this data was by using the database system. In other words, it was a very good (for the time and market) implementation of a Relational Database System. But the database facilities offered by Access far exceeded those offered by the OS. Access was not a DOS database system. It was a system built inside a DOS database system. Since that time, the OS has expanded a lot in some directions, not at all in others. In particular, DOS and Windows 3.x had no user-level security. Windows now does have user level security. Windows Servers now know not only which folders are shared, but who is allowed access to them. Windows servers now know not only which records are locked, but which user and computer has locked them. If Windows had had user-level security when Access was first written, Access might have used it. Instead, Access created its own system of keeping track of which users and groups had permissions, and which users and workstation locked records in the database. It did this on the one hand by using a database of users and groups, and on the other by using a database of logged-in users and record locks, which it implements by using OS-level record locks to lock the Access-level lock records There used to be some old white papers around which explained that clearly and with diagrams. Note, Record locks are not File locks, are not Page locks, are not Sector locks, are not Cluster locks, because OS-level data records are not sectors, clusters, files, pages, tables, Access-level records or anything other than what they a An old OS-level system for data records. This is all totally transparent to the user, as you would expect. One of the major aims of computer program development over the last 40 years has been to isolate function into separate levels and into separate islands, so that, for example, at the SQL level you, and your software, shouldn't have to know if you are using in-process or out-of-process, load-and-go or service, local or remote, OS or Application. The discussion here has shown just how successful that effort has been at the user-level. Anyway, there was a time when creating a new database from the command line was just as challenging to the average user as creating a new database from the command line would be to the average user now. When you would hide your server from the client tools because a user trying to restore (using RECOVER) an improperly deleted table (using DEL) would accidently destroy your whole database. When connect strings like "z:\SALES" were a foreign language. We are kind of at that stage with SQL Server now. People aren't familiar with the browser, or with the commands, or with the services or with the user interface. They just aren't familiar. They don't see that underneath it's the same: they only see the superficial differences. And , unless you understand what is the same, you aren't actually going to understand how the differences play out. That's not the embarrassing ignorance about things like 'ports' and 'services'. It's the embarrassing ignorance of 'Access brings the whole file down', and it's the more advanced stuff like how SQL Server can work over a Cisco VPN using Windows security, and it's the ordinary stuff like understanding that you have to work with smaller recordsets when using SQL Server. So the lesson is: SQL Server is more familiar than you think it is. It's going to be the superficial differences you notice most. (david) |
Thread Tools | |
Display Modes | |
|
|