If you’ve done anything at all on the Web other than simple surfing, you’ve probably used a database. Of course, that database has been hidden behind a fancy user interface, but you’ve used one nonetheless.
Have you searched for books or other products at www.amazon.com or www.costco.com or any other online store? The information about the products for sale is kept in some kind of database.
Have you searched for web sites on www.google.com or www.yahoo.com or any other search engine? Information about web pages and the data in them is kept is some kind of database.
Have you looked for information about public laws (thomas.loc.gov), driving directions (www.mapquest.com), or satellite imagery (www.terraserver.com)? This information is kept in some kind of database.
Most Java EE applications will include some kind of data-storage solution. Most often, that data-storage solution will be a relational database server of some kind. The database server may be an integral part of the application server, or it may be an application separate from the application server.
The examples can go on and on. The point should be clear though: Almost any type of nontrivial application will use a database of some kind. In the previous sentence, the term database is used in its loosest most general meaning as a collection of some data. That database could be anything from a text file of information for very simple applications to full-blown, enterprise-level relational or object databases for very complex systems. It could also include other data-storage systems, such as directories.
In any case, your application components need some means to communicate with the data-storage system. That is the job of JDBC. JDBC is a set of common APIs and system-specific libraries for communicating with a data-storage system. By communicating with the data-storage system through the common APIs, you can concentrate on the data, without needing to learn custom syntax for the particular data-storage system; that job is left to the system-specific library.
Most JDBC applications are used to communicate with a relational database. In a relational database, data is stored, conceptually, in tables. Each row in a table represents a set of data—a customer record, product information, a web site listing, and so on. And each column in the table represents a piece of data in that set. Tables can be linked by creating a relation between tables, thus it’s called a relational database. For example, a database might have a table of customer information and a table of information about orders. It makes no sense to repeat customer information for each order, so the orders table would include a customer ID that corresponds to a similar piece of data in the customers table, thus relating every order to a customer.
While JDBC is used most often with relational databases, it can be used with any data-storage system, as long as someone has created a system-specific library for that data-storage system.
Have you searched for books or other products at www.amazon.com or www.costco.com or any other online store? The information about the products for sale is kept in some kind of database.
Have you searched for web sites on www.google.com or www.yahoo.com or any other search engine? Information about web pages and the data in them is kept is some kind of database.
Have you looked for information about public laws (thomas.loc.gov), driving directions (www.mapquest.com), or satellite imagery (www.terraserver.com)? This information is kept in some kind of database.
Most Java EE applications will include some kind of data-storage solution. Most often, that data-storage solution will be a relational database server of some kind. The database server may be an integral part of the application server, or it may be an application separate from the application server.
The examples can go on and on. The point should be clear though: Almost any type of nontrivial application will use a database of some kind. In the previous sentence, the term database is used in its loosest most general meaning as a collection of some data. That database could be anything from a text file of information for very simple applications to full-blown, enterprise-level relational or object databases for very complex systems. It could also include other data-storage systems, such as directories.
In any case, your application components need some means to communicate with the data-storage system. That is the job of JDBC. JDBC is a set of common APIs and system-specific libraries for communicating with a data-storage system. By communicating with the data-storage system through the common APIs, you can concentrate on the data, without needing to learn custom syntax for the particular data-storage system; that job is left to the system-specific library.
Most JDBC applications are used to communicate with a relational database. In a relational database, data is stored, conceptually, in tables. Each row in a table represents a set of data—a customer record, product information, a web site listing, and so on. And each column in the table represents a piece of data in that set. Tables can be linked by creating a relation between tables, thus it’s called a relational database. For example, a database might have a table of customer information and a table of information about orders. It makes no sense to repeat customer information for each order, so the orders table would include a customer ID that corresponds to a similar piece of data in the customers table, thus relating every order to a customer.
While JDBC is used most often with relational databases, it can be used with any data-storage system, as long as someone has created a system-specific library for that data-storage system.
No comments:
Post a Comment