SQLite入门指南：移动开发者必备轻量级数据库

需积分: 9 11 浏览量更新于2024-07-21 1 收藏 2.85MB PDF 举报

《Introducing SQLite for Mobile Developers》是一本专门为Android和iOS开发者量身打造的轻量级且灵活的数据库指南。作者Jesse Feiler以其在移动开发领域的专业知识，为读者提供了SQLite的基础知识、SQL语言的必要技能以及如何有效地将数据库融入移动应用的实战步骤。这本书不仅适合有一定移动开发经验但对数据库理解有限的开发者，也适合作为初级开发者学习SQLite的入门读物。首先，本书从SQLite的基本概念开始，帮助读者理解什么是SQLite，它为何成为移动应用的理想选择。SQLite是一个嵌入式关系型数据库管理系统，由于其轻量级、无需服务器支持、易于集成的特点，特别适合在资源受限的移动设备上运行。接下来，书中会深入浅出地讲解SQL语言，包括基本的查询操作、数据表创建、更新和删除等，这些都是与SQLite交互的关键。通过实例演示，读者可以掌握如何编写有效的SQL语句来实现数据存储和检索。对于移动应用开发者来说，本书的核心内容在于指导如何在实际项目中整合SQLite。作者会详细介绍如何设计数据库架构，如何通过Android Studio或Xcode中的API将SQLite与Java或Swift编程语言结合，以便在Android的SQLiteOpenHelper或iOS的Core Data之外构建自己的数据存储模块。随着应用程序的开发进程，书中还会涉及如何处理数据同步、备份和恢复等问题，确保数据一致性。此外，一个章节专门探讨了应用生命周期管理，包括如何在启动、关闭、内存管理等不同阶段正确地管理SQLite连接，避免常见的性能瓶颈和资源浪费。最后，本书还强调了版权和使用规定，确保读者了解在合法范围内复制和传播内容的界限，尊重知识产权。整体而言，《Introducing SQLite for Mobile Developers》是一本实用且全面的资源，旨在帮助开发者充分利用SQLite为他们的移动应用带来强大的数据库功能。无论是初学者还是有经验的开发者，都能从中获得宝贵的知识和实践经验。

CHAPTER 1 ■ GETTING UP TO SPEED WITH DATABASES AND SQLITE

Databases Are Structured and Organized

All those examples can be implemented with a database because all those items need

to be structured and organized. Some of the items can turn into large amounts of

data (particularly a browser history if you don’t choose an option to clear out the old

information occasionally—another option that can be stored in a preference database),

but some of the preferences listed are very small amounts of data: even with a fully

modified file name for your download folder, 128 characters is enough to store that data

element. Furthermore, most browsers store the name of your preferred download folder,

but they don’t store the history of download folders (last week’s preferred download

folder, the folder you used last month, etc.).

In thinking about databases, “big” is often relevant, but very frequently it’s

misleading. It is structure and organization that matter most.

And they matter a great deal to a mobile developer.

Precisely because mobile devices need to function in a world of constrained

resources (e.g., limited storage space and battery power), structuring and organizing

the data that is stored is particularly important. Built into a data management system

are various optimizations that matter to databases large and small. For example, many

databases can store character or string data. Such data is typically quite variable. Even if

a database designer specifies that a text field can contain 50, 500, or 50,000 characters,

behind the scenes trailing blanks are often discarded. The user (and even the developer)

may never know this, but it makes the entire database function more efficiently. (Features

like this function behind the scenes and they can be accessed and turned on or off by the

database designer in many cases.)

Databases Are Smart

Being able to optimize storage to work with the presence or absence of characters in a

text field is a powerful behind-the-scenes tool, but databases have intelligence built

into them.

In most database engines today, the designer can specify many attributes of a field

such as the following:

• Name. A name that is used internally is often quite different from

the name that appears in the user interface.

• Type. You can specify that a certain database field must be an

integer or a string or any other type that the database supports.

• Optionality. Some fields are optional, and you can specify that

when you set up a database. (Many people have a car with a

license number; many other people do not own cars.)

• Default values. A database can be set to provide a default

value—either a simple value or a calculated value based on other

data in the database.

CHAPTER 1 ■ GETTING UP TO SPEED WITH DATABASES AND SQLITE

• Cardinality. Sometimes, there are multiple values for part of the

database. (To continue the example, some people have no car,

other people own a car, and others own several cars. Furthermore,

some people own a car and a bike . . . you get the idea.)

• Value ranges. When the database designer specifies the database

structure, a range of values for each field can be set. A driver’s

license identifier that consists of characters other than letters and

numbers (depending on the locality) may not be allowed.

• Value relationships. You can move beyond value ranges in

designing a database. You can create combinations of attributes

and values so that, for example, a database can enforce a rule that

an employee may be married (to one person or no one), but if the

employee is married, the spouse’s employer cannot be the same

as the employee’s employee. These restrictions in the database

reflect policies, but there well may be exceptions (a supervisor’s

approval), and the database can be designed to support a case

like that.

These are just a few of the ways in which a database can be set up to enforce

logical rules.

Perhaps at this point you’re tempted to say, “But I can do each of those things

with a line or two of code.” That’s absolutely true. But there are a couple of points to bear

in mind.

Writing Code Is Just the Beginning

You can write the code to implement any of those conditions, but that’s just the start.

Over time, conditions change, users have suggestions, and the Power That Be (whoever

that (or “they”) may be in your life) decides to change the rules for employment, cars,

the conditions that apply to license plate numbers, or any other things that strike his or

her fancy.

The code that took only a few lines of code and a couple of minutes to write needs to

be rewritten. And, although there is no clear research on the matter, it seems that these

changes take place at the last minute before a product (or version) launch and they must

be done immediately.

Parlez-vous Python? Sprechen Sie Scala?

The line or two that implement the rules for one of the data conditions may have been

written by someone who’s no longer around. Even if you wrote them, time may have passed

and you may not remember exactly what you were trying to implement (yes, commenting

your code is a desirable feature, but life happens . . .)

Those few lines of code may have been modeled on some code from a friend that

does exactly (or almost) what you want. Maintaining even the best-written code is a

challenge for everyone involved from the first author to the updater to the manager

and—eventually the user or manager who asks for “just a little tweak.”

CHAPTER 1 ■ GETTING UP TO SPEED WITH DATABASES AND SQLITE

Relational Databases and SQL to the Rescue

Today, databases are remarkably standardized in their structure—perhaps more so

than almost any other concept in the world of information technology. The idea of

a relational database was first proposed in 1970 by Edgar Codd, of IBM’s San Jose

Research Laboratory, and his proposal has become the basis for modern database

implementations (see article titled “A Relational Model of Data for Large Shared Data

Banks,” Communications of the ACM, 13(6), 377–387 (June 1970)).

In 1974, Donald D. Chamberlin and Raymond F. Boyce (also from IBM) wrote a paper

titled “SEQUEL: A Structured English Query Language” for the ACM (Association for

Computing Machinery) SIGFIDET Workshop on Data Description, Access and Control.

The relational model (proposed by Codd), together with SQL, has become the

basis for modern database implementations. Books by C. J. Date and others together

with Codd’s original work on the relational model remain the cornerstones of relational

database theory today.

■ Note The name SQL is derived from SEQUEL which turned out to be a trademark

of the Hawker Siddeley aircraft company. Today, many people suggest that SQL is not

an abbreviation or acronym but is a name in and of itself. Others suggest that SQL is an

acronym for structured query language.

The basic concepts of SQL are few. You can visualize them by thinking of a

spreadsheet with its rows and columns. (You can also conceptualize them using

mathematical set theory and other concepts, but spreadsheets are easier for many people

to think about today.)

Following are the basic SQL concepts:

• Table. A table is much like a simple spreadsheet with rows and

columns. (It’s not like a complex spreadsheet that may include

several tables. For this discussion, think simple—just rows and

columns in a single table.) A table is sometimes referred to as a

relation, but more often table is used.

• Column. A column represents a single data element such as

“address” or “name.” In the database world, a column may be

called a field. In the world of programming, a column may be

called an attribute or property.

• Row. A row represents single observations or set of values with

one for each column. Thus, a row in this imaginary simple

spreadsheet might represent a person’s data. In the database

world, a row may be called a record or tuple.

CHAPTER 1 ■ GETTING UP TO SPEED WITH DATABASES AND SQLITE

To retrieve data from a relational database table, you run a query. A query is a set

of logical instructions that manipulate a given table in such a way as to retrieve the data

that you want. The result of a query is another table. The resulting table may be empty

(if no data satisfies the query), it may be some or all of the data in the table, and, in

some complex queries, it may be larger than the basic table. The results of a query are

sometimes called a view or a result set.

These concepts and terms apply to most databases today regardless of the language

in which they are implemented and, perhaps more important, regardless of the database

engine or database management system (DBMS) in which they are implemented.

Furthermore, databases are sometimes implemented as part of frameworks and

languages. Thus, in PHP, you can use PDO (PHP Data Objects) starting with PHP 5.1 to

access SQLite. For iOS, you can use the Core Data framework to work with SQLite and

other data managers. In these cases as well as others, the idea has been to abstract as

much as possible into a framework or other wrapper so that switching databases does not

require massive rewrites of code.

SQLite implements most of the SQL standard. The exceptions are listed here

https://sqlite.org/omitted.html.

Looking Inside a Relational Table and Query

For the remainder of this chapter and several that follow, we are going to use a simple

example to learn how to create SQLtables and queries. Table1-1 shows a simple table that

can be used to demonstrate the basic concepts of SQL, queries, and relational tables. It

shows some data for a few people and their country of origin. The names of the columns

(fields) are PK, Name, and Origin. The values of Name are Cecelia, Leif, and Charlotte; the

values for Origin are Australia, Iceland, and United States.

Table 1-1. SimpleTable

PK Name Origin

1 Cecelia Australia

2 Leif Iceland

3 Charlotte United States

■ Note In a relational database, the columns have names, but rows are not named. In the

simple table shown in Table 1-1, the first column (named PK) has three values: 1, 2, and 3.

These values happen to correspond to the row numbers, but the sample would work just as

well if they were named Chair, Tree, and 15.

剩余155页未读，继续阅读

vanridin

粉丝: 108
资源: 1187

SQLite入门指南：移动开发者必备轻量级数据库

Introducing Gradle(Apress,2015)

Introducing SQLite for Mobile Developers 无水印pdf 0分

Introducing SQL Server(Apress,2015)

Introducing Windows 7 for Developers (pdf)

Introducing Meteor(Apress,2015)

Beginning Swift Games Development for iOS(Apress,2015)

Introducing Visual Basic 2005 for Developers的introduction

Introducing Visual Basic 2005 for Developers的第5章

Introducing Visual Basic 2005 for Developers的第4章

Introducing Visual Basic 2005 for Developers的第6章

最新资源