<!-- [if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:PunctuationKerning/>
<w:DrawingGridVerticalSpacing>7.8 磅</w:DrawingGridVerticalSpacing>
<w:DisplayHorizontalDrawingGridEvery>0</w:DisplayHorizontalDrawingGridEvery>
<w:DisplayVerticalDrawingGridEvery>2</w:DisplayVerticalDrawingGridEvery>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:Compatibility>
<w:SpaceForUL/>
<w:BalanceSingleByteDoubleByteWidth/>
<w:DoNotLeaveBackslashAlone/>
<w:ULTrailSpace/>
<w:DoNotExpandShiftReturn/>
<w:AdjustLineHeightInTable/>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:UseFELayout/>
</w:Compatibility>
<w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
</w:WordDocument>
</xml><![endif]--><!-- [if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" LatentStyleCount="156">
</w:LatentStyles>
</xml><![endif]--><!-- [if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:普通表格;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";
mso-ansi-language:#0400;
mso-fareast-language:#0400;
mso-bidi-language:#0400;}
</style>
<![endif]-->
大话数据库编程规范
节选自《剑破冰山——oracle开发艺术》一书,书籍销售地址:
http://product.china-pub.com/197199
http://product.dangdang.com/product.aspx?product_id=20981228&ref=book-02-L
http://www.amazon.cn/mn/detailApp?uid=477-1785695-2022958&ref=RK&asin=B004CMIVM6
目前在软件圈内有这么一个现象,就是:DBA
不太懂写PL/SQL
,而开发人员写的又是五花八门,而且效率不高。如此以来,造成诸多弊端:
1.
可读性差。读别人写的一个程序花费的时间,比自己写一个程序的花费时间还要长;非但别人看不懂,时间久了连自己也看不懂了。
2.
可维护性差。程序越写越长,越改越烂,像懒婆娘的裹脚布,又臭又长。
3.
可移植性差。今天用oracle
写一套,明天换成SQL Server
的时候再写一套,众多的数据库开发人员在程序的苦海中重复着低级劳动……
4.
效率和性能差。一个存储过程或SQL
执行效率简直可以让你感觉到对时间的绝望,你很快就理解什么是相对论了。
事实上为了统一软件开发过程中关于数据库设计时的命名规范和编程规范,正规一些的IT
公司都会制定一些关于数据库对象的命名和编程规范。
否则的话,你写你的我写我的,各自为战不兼容,彼此看不懂,甚至到最后连自己都弄不明白了,这样的经历相信每个人都曾经遇到过。
例如下面这段简单的代码,您看的明白吗?就算暂时明白,过个一年半载您还明白吗?就算您记忆超群,想必也会忘记,不是么?
A:=1;b:=2;SeLeCT
username from EmPLOyee where id=a aNd Type=b;
如果你改为下面这样的写法,相信稍微懂点数据库的人都应该看的明白不是?
vID:=1;
--A
为ID
vType=2;
--B
为类型
SELECT
username FROM employee WHERE id=vID AND type=vType;
丑陋的书写规范不仅可读性较差,而且给人以敬而远之的感觉,就是您是大侠也不行啊;而良好的书写规范则给人以享受和艺术的体验。
规则1.3.1.1
所有数据库关键字和保留字均使用大写;关于字段、变量的大小写风格在1.4
详细介绍。
规则 1.3.2.1
程序块严格采用缩进风格书写,保证代码清晰易读,风格一致,缩进格数统一为2 /4
个。
必须使用空格,不允许使用TAB
键。以免用不同的编辑器阅读程序时,因TAB
键所设置的空格数目不同而造成程序布局不整齐。
规则1.3.2.2
同一条语句需要占用多于一行时,每行的其它关键字与第一行的关键字进行右对齐。
IF flag=1 THEN
SELECT username
--
同上一行相比缩进4
个空格
INTO vuserinfo
--INTO
与SELECT
进行右对齐
FROM userinfo
--FROM
与SELECT
进行右对齐
WHERE userid=:iuserid;
--WHERE
与SELECT
进行右对齐
END IF;
规则1.3.3.1
不允许把多个语句写在一行中,即一行只写一条语句。
规则1.3.3.2
避免将复杂的SQL
语句写到同一行,建议要在关键字和谓词处换行。
规则1.3.3.3
相对独立的程序块之间必须加空行。
BEGIN
、END
独立成行
规则1.3.3.4
太长的表达式应在低优先级操作符处换行,操作符或关键字放在新行之首。划分出新行应当适当地缩进,使排版整齐,语句可读。
不同类型的操作符混合使用时,建议使用括号进行隔离,以使代码清晰。
规则1.3.3.5
减少控制语句的检查次数,如在 IF…ELSE
控制语句中,对最常用符合条件,尽量前置以被检查到。
DECLARE
--
定义局部变量
vFlag VARCHAR2(10);
--
判断标志
…
BEGIN
IF ((a=b AND a=c AND a=d) OR
--
在OR
处断行,可使得逻辑更为清晰
(a=e AND e=f)) THEN
--Process something
IF
vFlag=1 THEN
--vFlag=1
为经常出现之条件,可有效减少判断检查次数
--Process something
ELSIF vFlag=2 THEN
--vFlag=2
为次之出现的条件
--Process something
ELSE
--Process something
END IF;
规则
1.3.4.1
避免使用SELECT *
语句;不要用*
来代替所有字段,应给出字段列表,以避免表结构发生变化时应用程序出现无法识别的情况。
规则
1.3.4.2
INSERT
语句必须给出字段列表,以避免表结构发生变化时发生编译错误。
规则
1.3.4.3
当一个PL/SQL
或SQL
语句中涉及到多个表时,始终使用别名来限定表名和字段名,这使其它人阅读起来更方便,避免了含义模糊的引用,并能够别名中清晰地判断出表名和相关字段名。
规则
1.3.4.4
确保变量和参数在类型和长度与表数据列类型和长度相匹配。说明:如果与表数据列宽度不匹配,则当较宽或较大的数据传进来时会产生运行异常。
DECLARE
--
定义相关表字段变量
vDeptNo
salary.Deptno%type;
--not
VARCHAR2(10)
,以适应变化
vEmployeeNo
salary.EmployeeNo%type; --not VARCHAR2(10)
,以适应变化
vSalary
salary.Salary%type;
--not
NUMBER
,以适应变化
BEGIN
--Process something
END;
一千个读者就有一千个哈姆雷特,对于命名规范来说,想做到完全统一的确是不可能的任务。命名规范更多的是个人层面的爱好,就算有命名规范,也不过是体现制订规范的相关人的爱好而已。
因此即使无法完全做到一致,但是我们仍然要尽量去遵守,必要的时候需要通过代码检查和专家评审来进行约束,因为一个不成熟的规范总会胜过没有规范。
在此仅提供几种常见的命名方法(
表和字段的命名方式雷同)
。
以用户权限字段/
表为例:
UserPrivilege
|
适合那些英文比较好,并且喜欢抑扬顿挫和有艺术美感的人。
|
userprivilege
|
适合那些英文好,且比较严谨的人,毕竟全部小写很容易与数据库关键字相区别。
|
tbl_user_privilege
|
适合那些做开发的人,开发的人会习惯性的给变量加前缀。
(
这里指表的命名,字段一般很少加前缀)
|
yhqx
|
热爱中文的人,前提是恐怕您得对这些缩写先做好相关备注,等大家习惯了才行。
|
实际上这几种命名规范各有千秋,很难去指责或否定哪种更好,完全取决于整个公司多数人的习惯,记住没有十全十美的命名规范,只有绝大多数人心甘情愿的去遵从了,那就是好的命名规范。
就我个人而言,我更偏向于第一种命名习惯。
规则
1.4.1.1
不建议使用数据库关键字和保留字(不建议并不意味着不能使用),只是为了避免不必要的冲突和麻烦;
例如name,id,level,remark,description
等等。
有兴趣的话,大家可以参考下SELECT * FROM v$reserved_words
WHERE reserved='Y'
实际上oracle
不建议大家使用v$reserved_words
表中所有的关键字,无奈这些关键字太多了;reserved='Y'
的关键字则是被完全禁止的。
规则
1.4.1.2
严禁使用带空格的名称来对字段和表命名;在产生数据库脚本并重新加载的时候可能会出现意想不到的错误而被迫终止。
用户自定义的数据库对象名包括表、视图、主外键、索引、触发器、函数、存储过程、序列、同义词、数据库链接、包和包体等等。
规则
1.4.2.1
其它对象的命名也与表和字段的命名规则类似,风格保持一致即可
规则
1.4.2.2
除数据库名称长度为1
-8
个字符,其余为1
-30
个字符,database
link
名称也不要超过30
个字符;
命名只能使用英文字母,数字和下划线
规则
1.4.2.3
除表外,其它各种对象的命名最好用不同的前缀加以区别。采用前缀的方式来命名对象则很容易通过排序对对象进行区别。
如在命名规范中各组成部分以_
分割,则前缀建议也以_
分割;反之则可加可不加
对象名
|
前缀
|
范例
|
表(table)
|
tbl_/t_
(
或不加前缀)
|
userinfo/t_user_info/
tbl_user_info
|
视图(view)
|
v_/v
|
v_user_info/vuserinfo
|
序列(sequence)
|
seq_
|
seq_user_info
|
簇(cluster)
|
c_
|
c_user_info
|
触发器(trigger)
|
trg_
|
trg_user_info
|
存储过程(procedure)
|
sp_/p_
|
sp_user_info/p_user_info
|
函数(function)
|
f_/fn_
|
fn_user_info/f_user_info
|
物化视图
(materialized
view)
|
mv_
|
mv_user_info
|
包和包体
(package &
package body)
|
pkg_
|
pkg_user_info
|
类和类体
(type & type
body)
|
typ_
|
typ_user_info
|
主键(primary key)
|
pk_
|
pk_user_info
|
外键(foreign key)
|
fk_
|
fk_user_info_fieldname
|
唯一索引(unique index)
|
uk_
|
uk_user_info_fieldname
|
普通索引(normal index)
|
idx_
|
idx_user_info_fieldname
|
位图索引(bitmap index)
|
bk_
|
bk_user_info_fieldname
|
同义词(synonym)
|
依据于所
分配的表所属模块/
模式
|
|
数据库链接(database link)
|
无特殊要求
|
|
规则1.5.1
所有PL/SQL
中的变量与对象命名规则相似
变量类型
|
前缀
|
范例
|
输入变量
|
i_/i
|
i_user_id/iuserid
|
输出变量
|
o_/o
|
o_user_name/ousername
|
输出输入变量
|
io_/io
|
io_user_name/iousername
|
普通变量
|
v_/v
|
v_user_id/vuserid
|
全局变量
|
gv_/gv
|
gv_user_id/gvuserid
|
常量
|
大写
|
PI
|
游标
|
cur_
|
cur_userinfo
|
用户自定义类型
|
type_
|
type_user_info
|
保存点(save point)
|
spt_
|
spt_user_info
|
规则1.5.2
命名不允许使用中文或者特殊字符。
命名中若使用特殊约定或缩写,则要注释说明。
规则1.5.3
使用有意义、易于记忆、描述性强、简短及唯一的英文单词/
拼音缩写。自己特有的命名风格,要自始自终保持一致,不可来回变化。
说明:个人命名风格,在符合所在项目组的命名规则的前提下,才可以使用。
规则1.5.4
对于变量命名,禁止取单个字符(
如i
、j
… )
,建议除了要有具体含义外,还能表明变量类型等。
说明:变量,尤其是局部变量,如果用单个字符表示,很容易敲错(
如i
写成j)
,而编译时又检查不出来,有可能为了这个小小的错误而花费大量的时间。
注释规范是判断一个开发人员优劣和成熟度的重要指标。一个优秀的研发人员必然是经过深思熟虑然后才洋洋洒洒妙笔生花的,注释的书写体现了一个人思考问题的全过程和步骤;话又说回来,就算代码写的烂,只要注释写的好,至少也会给人以良好的感觉;同时也能造福后人,不是么?呵呵。
规则1.6.
1
一般情况下,源程序有效注释量必须在30%
左右。
说明:注释的原则是有助于对程序阅读理解,在该加的地方都加了,注释不宜太多也不能太少,注释语言须准确、易懂、简洁、精炼。
规则1.6.
2
统一文件头的注释.
主要是对相关过程、函数进行功能性描述、修订记录、以及入参出参说明
对存储过程、函数的任何修改,都需要在注释后添加修改人、修改日期及修改原因等修订说明。
/***********************************************************
名称: sp_xxx
功能描述:
修订记录:
版本号
编辑时间
编辑人
修改描述
1.0.0
2010-01-01
John
1
、创建此存储过程
1.0.1
2010-02-01
Sandy
2
、增加传入参数
入参出参描述:
iparameter1
IN VARCHAR2(20)
传入参数1
iparameter2
IN VARCHAR2(20)
传入参数2
iparameter1
OUT VARCHAR2(20)
传入参数1
iparameter2
OUT VARCHAR2(20)
传入参数2
返回值描述:(
主要针对函数)
0 - Success
1 - normal fail
***********************************************************/
规则1.6.
3
所有变量定义需要加注释,说明该变量的用途和含义。
规则1.6.
4
注释内容要清晰、明了、含义准确,防止注释二义性
在代码的功能、意图层次上进行注释,提供有用、额外的信息。
避免在一行代码或表达式的中间插入注释。
尽量使用”--
”进行注释;行尾注释须使用”--
”。
规则1.6.
5
对程序分支必须书写注释。
说明:这些语句往往是程序实现某一特定功能的关键,对于维护人员来说,良好的注释帮助更好的理解程序,有时甚至优于看设计文档。
在程序块的结束行右方加注释,以表明程序块结束。
规则1.6.
6
注释应与其描述的代码相似,对代码注释应放在其上方或右方(
对单条语句的注释)
相近位置,不可放在下面。
注释与所描述的内容进行同样的缩排。
注释上面的代码应空行隔开。
建议1.6.
7
注释用中文书写
有一次,同事写了一个900
行的存储过程,里面定义了十几个游标以进行遍历,这个存储过程缺乏注释,执行一次居然要一天一夜,已经达到了无法容忍的地步。
因为缺乏注释,我花了整整一天的时间来对该存储过程进行分析,然后用了半天时间来进行改写和调试。
其实很简单定义,我定义了一些对应的临时表,把游标遍历替换成SQL
的集合操作,把整个的一个大事务分割成若干小事务,只是修改了部分代码,结果执行时间就变成了短短的3
分钟。
当然游标也并非不可触及的,既然存在就有他存在的理由。
良好的语法规范有助于书写出高效、完备的PL/SQL
程序,同时有助于提高系统的容错性、健壮性、可追溯性。
规则1.7
.1
避免隐式的数据类型转换。
说明:在书写代码时,必须确定表的结构和表中各个字段的数据类型,特别是书写查询条件时的字段就更要注意了。这个是导致SQL
性能不佳常犯的错误之一。
规则1.7
.2
为了方便不同的数据库平台的移植,尽量使用SQL99
标准,而不要使用Oracle
的方言。
例如:DECODE
函数完全可以用CASE WHEN
语句代替,而且可编程性更强。
(+)=
右关联用RIGHT OUTER JOIN
语句代替。
=(+)
左关联用 LEFT OUTER JOIN
语句代替。
规则1.7
.3
对于非常复杂的SQL(
特别是多层嵌套,带子句或相关的查询)
,应该先考虑是否设计不当引起的,对于复杂的一些SQL
可以考虑使用程序实现,原则上遵循一句话只做一件事情。
关于处理的优先级
1、
静态SQL>
动态SQL
2、
绑定变量的SQL>
动态SQL
(在OLTP
系统中建议这么做)
3、
SQL>PL/SQL
的过程,极端复杂的SQL
除外
4、
SQL>
游标遍历
5、
Oracle
函数>
自定义函数
6
、尽量使用Oracle
分析函数代替同一个表多次的关联。
规则1.7
.4
原则上不要使用动态SQL
,如果非得使用动态SQL
,建议使用绑定变量。
规则1.7
.5
一定要及时关闭和释放游标
规则1.7
.6
建议在异常处理中,把收集到错误信息记入错误日志表,以备查询和分析。
CREATE OR REPLACE PROCEDURE
sp_increament_xxx
/***********************************************************
名称: sp_increament_xxx
功能描述:xxx
表/
模块数据增量更新,错误原因分析通过tbl_task_table
日志表
修订记录:
版本号
编辑时间
编辑人
修改描述
1.0.0
2010-05-01
John
1
、创建此存储过程
1.0.1
2010-06-01
Sandy
2
、更新xxx
字段在xxx
处
入参出参描述:
N/A
返回值描述:(
主要针对函数)
N/A
***********************************************************/
AS
v_err_num NUMBER;
v_err_msg VARCHAR2(100);
v_begin_date DATE;
v_end_date DATE;
BEGIN
v_err_num:=0;
v_err_msg:='';
--
某表增量更新步骤
BEGIN
SAVEPOINT spt_xxx;
--
从任务表中获取更新初始时间
SELECT lasttime INTO v_begin_date FROM
tbl_task_table T
WHERE id='sp_increament_xxx';
--
从源数据表中获取更新最后时间
SELECT MAX(oper_date) INTO v_end_date FROM tbl_table_source;
--
为提高执行效率,将增量数据写入临时表中
INSERT INTO tmp_tbl_table_source
(fieldname1,fieldname2,fieldname3,
fieldname4,fieldname5,fieldname6)
SELECT
fieldname1,fieldname2,fieldname3,
fieldname4,fieldname5,fieldname6
FROM tbl_table_source sourcetable
WHERE sourcetable.create_date > v_begin_date
AND sourcetable.create_date <=
v_end_date;
--
再讲增量数据从临时表更新到最终目标表
MERGE INTO tbl_table_original_dest desttable
USING tmp_tbl_table_source
tmptable
ON (desttable.primarykey =
tmptable.primarykey) --
匹配判断标准,根据主键判断
WHEN MATCHED THEN
--
如果已存在,更新原纪录
UPDATE SET desttable.fieldname1 = tmptable.fieldname1,
desttable.fieldname1 =
tmptable.fieldname1,
desttable.fieldnamem =
tmptable.fieldnamem,
desttable.fieldnamen =
tmptable.fieldnamen
WHEN NOT MATCHED THEN
--
如果不存在,插入新纪录
INSERT (fieldname1,fieldname2,fieldname3,
fieldname4,fieldname5,fieldname6)
VALUES (tmptable.fieldname1,tmptable.fieldname2,tmptable.fieldname3,
tmptable.fieldname4,tmptable.fieldname5,tmptable.fieldname6);
--
更新任务表相应的状态、时间
UPDATE tbl_task_table
SET
lasttime_=v_end_date,status='SUCCESS'
WHERE id='sp_increament_xxx';
COMMIT;
--
异常处理,把错误记入相关日志表,可以及时找到错误原因并进行分析。
EXCEPTION
WHEN OTHERS THEN
ROLLBACK TO SAVEPOINT spt_xxx;
v_err_num := SQLCODE;
v_err_msg := SUBSTR(SQLERRM, 1,
100);
UPDATE tbl_task_table
SET
lasttime_=v_begin_date,status='FAIL'
WHERE id='sp_increament_xxx';
COMMIT;
END;
--
某表增量更新步骤
BEGIN
...
END;
END;
本例为数据库定时调用存储过程,同时也只是为了演示存储过程的全部过程;对于常用的由客户端调用的存储过程,建议不要捕获异常,而由客户程序进行直接处理。
规则1.7
.7
不要将空的变量值直接与比较运算符(
符号)
比较。如果变量可能为空,应使用IS NULL
或IS NOT NULL
或NVL
函数进行比较。
规则1.7
.8
尽可能地使用相关表字段的类型定义,形如%TYPE
、%ROWTYPE
。这样做当表结构发生变动的时候,能够最大程度的做到容错性和健壮性。
规则1.7
.9
存储过程中变量的声明应集中在AS
和BEGIN
关键字之间,不允许在代码中随意定义变量,定义变量时,完成相同功能模块的变量应放在一起,与不同模块的变量应空行隔开,增加代码的可读性。
脚本规范有助于进行版本基线的管理、版本控制,也有助于系统的自动部署、定位和解决部署过程中出现的问题。
规则 1.8.1
所有脚本按分类或内容分开存放,并按以下顺序存储:
1.
创建数据库角色、用户脚本
2.
创建数据库表空间、数据文件脚本
3.
创建数据类型脚本,自定义的数据类型
4.
创建业务表脚本,表是其他依赖关系的基础
5.
创建临时表脚本,可能会在过程脚本中用到
6.
创建视图脚本
7.
创建主外键脚本
8.
创建索引脚本
9.
创建触发器脚本
10.
创建函数、存储过程脚本
11.
初始化数据脚本
12.
创建作业脚本
规则1.8.2
创建每个对象代码的首部应该有对象注释
规则1.8.3
每个函数、存储过程应单独创建脚本,在配置库上按照功能模块存放到不同的目录下。
并在相应的目录下,创建一个运行所有脚本的总脚本。
分享到:
相关推荐
### Oracle剪破冰山:大话数据库编程规范 #### 编程规范的重要性 在软件行业中,特别是涉及到数据库应用开发的领域,存在着一个普遍的问题:**数据库管理员(DBA)往往不擅长编写PL/SQL代码**,而那些负责开发工作...
- **代码规范**:遵循良好的编程习惯,避免过度设计和冗余代码,保持代码简洁清晰,减少维护成本。 - **设计模式**:熟练运用设计模式可以提高代码复用性,降低耦合,间接提升性能。 通过上述知识点的学习和实践...
4. 代码规范与重构:遵循良好的编程习惯,提高代码可读性和可维护性。 通过《大话企业级Android开发全集》的学习,读者不仅能掌握Android开发的基础,还能了解到企业级开发中的最佳实践,为今后的Android职业生涯...
【大话XML1.2】是一篇介绍XML基础和重要性的文章,主要面向程序员和对IT技术感兴趣的读者。XML(可扩展标记语言)是W3C组织定义的标准,已经成为当前软件行业的主流技术,尤其在微软的Office XP、.NET框架和SQL ...
9. **数据存储**:熟悉SQLite数据库的使用,包括创建表、插入、查询、更新和删除数据,以及如何优化数据库性能。 10. **网络编程**:学习使用HttpURLConnection、OkHttp等库进行HTTP请求,理解JSON格式数据的解析,...
此外,理解Material Design规范和使用Android Studio提供的设计工具,如Vector Asset Studio和Layout Inspector,能帮助创建符合现代审美的应用界面。 2. 日志调试: 在开发过程中,日志记录和调试是必不可少的...
此外,还要学习自定义视图、手势检测以及Material Design设计规范,以实现专业且用户友好的界面。 Android应用的存储管理也是关键知识点。内部存储、外部存储以及SQLite数据库是常见的数据存储方式。理解何时使用哪...
该文档提供的内容并非传统的IT知识,而是一份改编自经典电影《大话西游》的搞笑剧本,适合娱乐和表演用途。...如果需要更深入的IT知识,例如编程语言、网络架构、数据库管理等,请提供更具体的相关内容。
7. **网络编程**:Android应用常常需要与服务器交互,这涉及网络编程。书中会讲解HTTP请求、JSON解析、OkHttp库的使用,以及如何处理异步任务。 8. **多线程与异步处理**:Android开发中,多线程和异步处理是必不可...
《大话企业级Android开发》一书主要涵盖了在企业环境中进行高效、稳定且高质量的Android应用开发所需的各种技术和实践。Android作为全球最广泛使用的移动操作系统,其开发领域涉及的范围广泛,包括系统架构、UI设计...
《大话企业级Android开发》是一本深入探讨企业级Android应用开发的专业书籍,涵盖了从基础到高级的全方位知识。在1-14章的内容中,读者可以系统地学习到Android开发的各种关键技术和实践策略,为成为一名优秀的...
《大话企业级Android开发》是一本专注于深入探讨企业级Android应用开发的资源包。它涵盖了从基础到高级,从理论到实践的各种知识点,旨在帮助开发者提升在Android平台上的专业技能,以应对复杂的商业需求。这个...
6. **数据存储**:书中会介绍SQLite数据库的使用,包括创建表、插入、查询和更新数据,同时也会提及SharedPreferences和文件存储的方式。 7. **网络编程**:Android应用经常需要与服务器进行数据交换,因此,HTTP...
在编程领域,设计模式是一种被广泛认可的解决常见问题的最佳实践。它们是经过时间验证的、可重用的解决方案模板,适用于软件设计中的特定情境。标题"设计模式--大话设计"表明我们将深入探讨设计模式的奥秘,尤其是在...
Android 提供多种数据存储方式,包括SQLite数据库、SharedPreferences、文件系统、ContentProvider等,开发者需根据需求选择合适的数据存储策略。 七、性能优化 性能优化是Android开发中的重要环节,包括内存优化、...
除此之外,Android的UI设计遵循Material Design设计规范,开发者需要熟悉布局管理器(如LinearLayout、RelativeLayout、ConstraintLayout)和各种视图控件,以创建符合用户习惯的界面。同时,理解如何处理触摸事件、...
2. **Java Persistence API (JPA)**:这是JavaEE5中的一个重要部分,提供了统一的ORM(对象关系映射)规范,使得开发者可以通过简单的API操作数据库,而无需直接编写SQL语句。 3. **JavaServer Faces (JSF)**:...