⑴ 数据库里为什么存编号，不直接存编号对应的值，从页面显示的时候，还要根据所存的编号查询对应的值。
这种表属于基础档案表, 这样做的好处是其他表中如果用到性别这个属性的列可以直接保存0 1 2
而不用保存‘男’女‘变态’
试想一下如果很多张表中都要用到这个性别属性, 如果不使用保存编号的话, 那么表将变的非常冗长, 另外用编号方便维护, 只有改动基础表就可以了, 所有外围的表都同时指向基础档案表, 视图查询, 高效简洁易于扩展和程序的维护。
⑵ ACCESS数据库如何实现自动编号
这个可以在excel里面做好80000-90000的编号，excel里面你知道的啊，开头写两个编号，然后框住，往下一拖，拖够你要的行数就行啦！
然后复制进Access，完成！
⑶ 什么叫数据库的“编码方式”啊请具体一点，我IT菜鸟
就是数据库的编码是什么的 对于数据库来说也就是存储数据的编码方式 类似程序 也有GBK UTF-8 ISO8859-1等等
⑷ 怎么查看mysql的数据库编码格式
1、查看数据库编码格式
mysql>showvariableslike'character_set_database'
2、查看数据表的编码格式
mysql>showcreatetable<表名>;
3、创建数据库时指定数据库的字符集
mysql>createdatabase<数据库名>charactersetutf8;
4、创建数据表时指定数据表的编码格式
createtabletb_books(
namevarchar(45)notnull,
pricedoublenotnull,
bookCountintnotnull,
authorvarchar(45)notnull)defaultcharset=utf8;
5、修改数据库的编码格式
mysql>alterdatabase<数据库名>charactersetutf8;
6、修改数据表格编码格式
mysql>altertable<表名>charactersetutf8;
7、修改字段编码格式
mysql>altertable<表名>change<字段名><字段名><类型>charactersetutf8;
mysql>(20)charactersetutf8notnull;
⑸ mysql数据库某一个表中，存储会员号和密码
存的时候用md5加密，登录的时候先把密码用md5加密再和数据库比较;
md5只是其中一种加密方式，你也可以用别的算法
⑹ sql数据库，客户注册有两个级别,如果是J级别,则生成会员编码J+7为随机数,
最基础的办法但是运行效率不高。就是生成一个查一下数据库。这样肯定能保证不重复，但是运行效率慢，需要不断的查询数据库。最好是有个生成规则。比如客户端的mac地址等，之前解决过一次这样的问题，生成16位唯一识别码。采用的是用户名加随机数的形式。用户名肯定不会允许重复，建议从这方面下下工夫。
⑺ mysql编码数据库，数据表，字段各用什么编码
1. ASCII
用途：用来映射简单的单字节字符，比如大小写英文字母、阿拉伯数字、常用的标点符、运算符、控制字符等。
编码范围：U+0000 - U+007F
注意：对于用这类字符的场景够用了，但是却无法表达比如汉字，日文等编码。
2. UNICODE
用途：用来映射包含 ASCII 以内的其他的所有字符。
编码范围：U+0000 - U+10FFFF
注意：ASCII 是 UNICODE 的子集，ASCII 编码的字符可以无损转换为 UNICODE 编码的字符。
MySQL 常用字符集
1. Latin1
Latin1 是 cp1252 或者 ISO-8859-1 的别名。ISO-8859-1 编码是单字节编码，向下兼容 ASCII。
编码范围：U+0000 - U+00FF
ISO-8859-1 收录的字符除 ASCII 收录的字符外，还包括西欧语言、希腊语、泰语、阿拉伯语、希伯来语对应的文字符号。
单字节内的空间都被 ISO-8859-1 编码占用，所以能够用 ISO-8859-1 编码存储、传输其他任何编码的字节流。
比如把一个 Utf8mb4 的编码或者 GBK 的编码存入 Latin1，不会有任何问题。因为 Latin1 保留了原始的字节流，这也就是 MySQL 长期以来把 Latin1 做默认字符集的原因。
但是由于 Latin1 对任何字符都存放字节流，造成了字符个数的浪费。
比如：
CHAR(10) CHARACTER SET LATIN1;CHAR(10) CHARACTER SET UTF8;
该字段中存储字符个数 UTF8 是 Latin1 的三倍！！！
2. GB18030
GB18030 是中国官方标准字符集，向前兼容 GBK、GB2312，是这两个的超集。用 1、2、4 个字节分别表示一个符号。比如对一般中文字符，默认是用两个字节编码存储。Windows 系统，默认用的就是 GB18030。
若只是存储中文字符，那 GB18030 最佳。
原因有两点：
1）占用空间小，比如比 UTF8 小。
2）存储的汉字根据拼音来排序，检索快。
3. UTF8
UTF8 是 Unicode 的编码实现，可以存储 UNICODE 编码对应的任何字符， 这也是使用最多的一种编码。最大的特点就是变长的编码方式，用 1 到 4 个字节表示一个符号，可以根据不同的符号编码字节长度。
字母或数字用 1 字节，汉字用 3 字节，emoji 表情符号用 4 字节。UTF8 字符集目前是使用最广泛的。
注意！MySQL 里常说的 UTF8 是 UTF8MB3 的别名，UTF8MB3 是 UTF8MB4 的子集，UTF8MB4 才是真正的 4 字节 UTF8 字符集！
UTF8MB3 表示最大支持 3 个字节存储字符，UTF8MB4 表示最大 4 个字节存储字符。根据实际需要和未来展望，MySQL 8.0 已经默认用 UTF8MB4 基础字符集。
⑻ mysql应该用什么编码格式储存在数据库里呢
mysql中一般用UTF-8编码。
UTF-8（8-bit Unicode Transformation Format）是一种针对Unicode的可变长度字符编码，又称万国码。由Ken Thompson于1992年创建。现在已经标准化为RFC 3629。UTF-8用1到6个字节编码UNICODE字符。用在网页上可以同一页面显示中文简体繁体及其它语言（如英文，日文，韩文）。
修改数据库编码的命令为：
alterdatabaseapp_relationcharactersetutf8;
它相当于下面的三句指令：
SETcharacter_set_client=utf8;
SETcharacter_set_results=utf8;
SETcharacter_set_connection=utf8;
⑼ 关于mysql数据库字符编码的问题、中文乱码！
一、转码失败
在数据写入到表的过程中转码失败，数据库端也没有进行恰当的处理，导致存放在表里的数据乱码。
针对这种情况，前几篇文章介绍过客户端发送请求到服务端。
其中任意一个编码不一致，都会导致表里的数据存入不正确的编码而产生乱码。
比如下面简单一条语句：
set @a = "文本字符串";
insert into t1 values(@a);
1. 变量 @a 的字符编码是由参数 CHARACTER_SET_CLIENT 决定的，假设此时编码为 A，也就是变量 @a 的编码。
2. 写入语句在发送到 MySQL 服务端之前的编码由 CHARACTER_SET_CONNECTION 决定，假设此时编码为 B。
3. 经过 MySQL 一系列词法，语法解析等处理后，写入到表 t1，表 t1 的编码为 C。
那这里编码 A、编码 B、编码 C 如果不兼容，写入的数据就直接乱码。
二、客户端乱码
表数据正常，但是客户端展示后出现乱码。
这一类场景，指的是从 MySQL 表里拿数据出来返回到客户端，MySQL 里的数据本身没有问题。客户端发送请求到 MySQL，表的编码为 D，从 MySQL 拿到记录结果传输到客户端，此时记录编码为 E（CHARACTER_SET_RESULTS）。
那以上编码 E 和 D 如果不兼容，检索出来的数据就看起来乱码了。但是由于数据本身没有被破坏，所以换个兼容的编码就可以获取正确的结果。
这一类又分为以下三个不同的小类：
1)字段编码和表一致，客户端是不同的编码
比如下面例子， 表数据的编码是 utf8mb4，而 SESSION 1 发起的连接编码为 gbk。那由于编码不兼容，检索出来的数据肯定为乱码。
2）表编码和客户端的编码一致，但是记录之间编码存在不一致的情形
比如表编码是 utf8mb4，应用端编码也是 utf8mb4，但是表里的数据可能一半编码是 utf8mb4，另外一半是 gbk。那么此时表的数据也是正常的，不过此时采用哪种编码都读不到所有完整的数据。这样数据产生的原因很多，比如其中一种可能性就是表编码多次变更而且每次变更不彻底导致（变更不彻底，我之前的篇章里有介绍）。举个例子，表 t3 的编码之前是 utf8mb4，现在是 gbk，而且两次编码期间都被写入了正常的数据。
3）每个字段的编码不一致，导致乱码
和第二点一样的场景。不同的是：非记录间的编码不统一，而是每个字段编码不统一。举个例子，表 c1 字段 a1,a2。a1 编码 gbk，a2 编码是 utf8mb4。那每个字段单独读出来数据是完整的，但是所有字段一起读出来，数据总会有一部分乱码。
三、LATIN1
还有一种情形就是以 LATIN1 的编码存储数据
估计大家都知道字符集 LATIN1，LATIN1 对所有字符都是单字节流处理，遇到不能处理的字节流，保持原样，那么在以上两种存入和检索的过程中都能保证数据一致，所以 MySQL 长期以来默认的编码都是 LATIN1。这种情形，看起来也没啥不对的点，数据也没乱码，那为什么还有选用其他的编码呢？原因就是对字符存储的字节数不一样，比如 emoji 字符 "❤"，如果用 utf8mb4 存储，占用 3 个字节，那 varchar(12) 就能存放 12 个字符，但是换成 LATIN1，只能存 4 个字符。
⑽ PhpMyAdmin数据库里面存储用户密码的话，应该选哪种编码方式
如果是网站或者软件，应该和网站或软件编码一致，如果是独立的数据库，选择utf-8或者gb2312都可以！