Topic 3: Database servers

Types of databases

Database servers have long been the client/server arena for development.

Flatfile

The flat file database, is usually just a text file. It can suit many applications whereby the database's to function like a rolodex. The records can be delimited, non-delimited or position delimited. The delimited records can be by CSV (comma-quote) or a Tab character in the text.

Relational DBMS

The relational model has advantages of 'one to many' between tables and the use of simultaneous updates. Many are ODBC/SQL compliant, allowing communication across data sources/servers.

Object-oriented OODBMS

The object oriented model has data objects which are encapsulated by classes that have pre-defined characteristics. Such as a player, room or container classes used in virtual worlds and multi-user games. Objects added to the database automatically acquire (inherit) the characteristics of their class. These data are accessible only through messages which they recognise. The ZOPE application server from zope.org uses an OODBMS inside its core as shown in Figure 3.1.

The CouchDB

Apache CouchDB is a distributed, schema-free document-oriented database accessible via a RESTful HTTP/JSON API with JavaScript as the main view definition language.

Database servers can use Thick or Thin clients. In a thick client like a modern Web browser, the client does much of the work, and so is

relatively large and complex. A thin client is simple and light as the server handles most of the work, but can be network intensive.

2- and 3-tier database models

The 2-tier database model is a standalone application with data tightly bound, and includes many mainframe and workgroup database systems. Microsoft Access, as an example, may have all actions take place within a single Visual Basic application and the data may be in a separate or integrated file.

The 3-tier model is more popular for business, where the database backend is an Enterprise Relational Database such as Sybase or Oracle - with generally no direct access to the database. A Middleware component (API, controls or scripts) does most of the work in controlling access, building relational database tables and tracking changes. The clients are either thin, a Web browser, or a custom application - and of more than one type. The API support usually includes Perl, C, Java and Python, as well as Web submission forms, e.g. MyCSU and the CSU E-box system.

The advantages of the 3-tier database model are load distribution; transparency (changes at one level transparent at other levels, e.g. New client or backend); the ease of building custom application, business and data rules; as well as security controlled at the middleware layer.

Database design issues

Consider the following design aspects:

The number of users

1. How will the system scale? Does it need to?

2. What's your timeline?

3. What kind of output do you need?

4. Paper forms, web, wireless devices?

5. Will your application serve all needs?

Security issues

1. Where is your security coming from?

2. Who needs access to what?

3. Need for agility in your code base.

4. Will you need to migrate? (Yes, you will!)

5. Do you need to add specialised applications?

Take a video lesson under 10 minutes

A: Microsoft SQL Server 2008: http://www.youtube.com/watch?v=gfzEZTiGNIc

or at http://www.microsoft.com/latam/sql/2008/learning/presentations.mspx

B: phpMyAdmin Tutorial at:

http://www.youtube.com/watch?v=1-81n_vuwug&feature=related