T********i
发帖数: 2416 | 1 比如SQLITE。
CREATE TABLE sometable(Id INTEGER PRIMARY KEY)
简单吧？就是一个整数数组。而且是PRIMARY KEY
现在：
SELECT MAX(ID) from sometable
50万数竟然将近一分钟！不就是二叉树么？竟然是O(n)，而不是O(Log(n))
上网查是没结果的！只能试
CREATE TABLE sometable(Id INTEGER PRIMARY KEY NOT NULL)
这次只要5秒钟了！
问题是，PRIMARY KEY就隐含NOT NULL啊！所有教科书都是这么讲！
这个是不是SQLITE特有问题？我不知道！
但是
SELECT MAX(ID)，MIN(ID) from sometable
不能被优化，是所有数据库的通病！你不能想象优化这个有多难！结果是分开运行10秒
钟，放到一个query 2分钟！ |
c*******v
发帖数: 2599 | 2 In SQL standard, the primary key column must not contain NULL values. It
means that the primary key column has an implicit NOT NULL constraint.
However, to make the current version of SQLite compatible with the earlier
version, SQLite allows the primary key column to contain NULL values.
----https://www.sqlitetutorial.net/sqlite-primary-key/
我刚刚查到的，不知真假。
【在 T********i 的大作中提到】
: 比如SQLITE。
: CREATE TABLE sometable(Id INTEGER PRIMARY KEY)
: 简单吧？就是一个整数数组。而且是PRIMARY KEY
: 现在：
: SELECT MAX(ID) from sometable
: 50万数竟然将近一分钟！不就是二叉树么？竟然是O(n)，而不是O(Log(n))
: 上网查是没结果的！只能试
: CREATE TABLE sometable(Id INTEGER PRIMARY KEY NOT NULL)
: 这次只要5秒钟了！
: 问题是，PRIMARY KEY就隐含NOT NULL啊！所有教科书都是这么讲！
|
T********i
发帖数: 2416 | 3 那个其实也不是重点。
重点是primary key，不管有没有null, 都是带 unique index的。
因此优化的代码是一样的。而且你搜一下，这样做的很多，大家都建议单独选min或者
max。而且都是简单的 Primary key 。其中很多 Sqlite 用户。
都是睁眼说瞎话。
: In SQL standard, the primary key column must not contain NULL values.
It
: means that the primary key column has an implicit NOT NULL constraint.
: However, to make the current version of SQLite compatible with the
earlier
: version, SQLite allows the primary key column to contain NULL values.
: ----https://www.sqlitetutorial.net/sqlite-primary-key/
: 我刚刚查到的，不知真假。
【在 c*******v 的大作中提到】
: In SQL standard, the primary key column must not contain NULL values. It
: means that the primary key column has an implicit NOT NULL constraint.
: However, to make the current version of SQLite compatible with the earlier
: version, SQLite allows the primary key column to contain NULL values.
: ----https://www.sqlitetutorial.net/sqlite-primary-key/
: 我刚刚查到的，不知真假。
|
m**e
发帖数: 12 | 4 人笨怪刀钝，如果primary key允许null, 还怎么保证unique。你还是先去搞懂b-tree,
再来喷。
.
constraint.
【在 T********i 的大作中提到】
: 那个其实也不是重点。
: 重点是primary key，不管有没有null, 都是带 unique index的。
: 因此优化的代码是一样的。而且你搜一下，这样做的很多，大家都建议单独选min或者
: max。而且都是简单的 Primary key 。其中很多 Sqlite 用户。
: 都是睁眼说瞎话。
:
:
: In SQL standard, the primary key column must not contain NULL values.
: It
:
: means that the primary key column has an implicit NOT NULL constraint.
:
: However, to make the current version of SQLite compatible with the
|
T********i
发帖数: 2416 | 5 这事儿你应该去问sqlite。怎么来问我？
难道你天生就知道Sqlite咋实现的？真是不世出的天才！
: 人笨怪刀钝，如果primary key允许null, 还怎么保证unique。你还是先去搞懂b
-tree,
: 再来喷。
: .
: constraint.
【在 m**e 的大作中提到】
: 人笨怪刀钝，如果primary key允许null, 还怎么保证unique。你还是先去搞懂b-tree,
: 再来喷。
:
: .
: constraint.
|
m**e
发帖数: 12 | 6 您才是不世出的大牛，您的iot理论是颠覆性的。我不过是知道一些数据库索引的皮毛
而已。
不过，我有点奇怪，您这种惜时如金的大牛，怎么会有时间，每天花这么多时间在这里
和我们这些凡夫俗子灌水呢？
懂b
【在 T********i 的大作中提到】
: 这事儿你应该去问sqlite。怎么来问我？
: 难道你天生就知道Sqlite咋实现的？真是不世出的天才！
:
:
: 人笨怪刀钝，如果primary key允许null, 还怎么保证unique。你还是先去搞懂b
: -tree,
:
: 再来喷。
:
: .
:
: constraint.
:
|
T********i
发帖数: 2416 | 7 这话我欣然领受。作为现代IoT系统的奠基人，责任重大。
你要是知道数据库索引，那就说说Sqlite的primary key咋索引的呗？很困难么？
我确实非常忙，但是我的时间100%自己掌握。每天都有必要的消遣。这个地儿好，想来
就来，想走就走，no string attached。
话说早期用户，每个Hub送1000个Device License。正在做这个label，发货的时候每个
Hub专门生成一个贴上。
【在 m**e 的大作中提到】
: 您才是不世出的大牛，您的iot理论是颠覆性的。我不过是知道一些数据库索引的皮毛
: 而已。
: 不过，我有点奇怪，您这种惜时如金的大牛，怎么会有时间，每天花这么多时间在这里
: 和我们这些凡夫俗子灌水呢？
:
: 懂b
|
m*******0
发帖数: 19 | 8 只有一个record的key是null的话，还是unique.
tree,
或者
【在 m**e 的大作中提到】
: 人笨怪刀钝，如果primary key允许null, 还怎么保证unique。你还是先去搞懂b-tree,
: 再来喷。
:
: .
: constraint.
|
T********i
发帖数: 2416 | 9 那个人有大量时间来喷，也不知道牵狗搜一下。
我当然是搜到Sqlite比较奇葩，允许null primary key value，才想到去fix。
老顾就知道去搜。
其实，即使sqlite允许多个null value做特例（non-null必须unique），也不应该影响
max的优化。
【在 m*******0 的大作中提到】
: 只有一个record的key是null的话，还是unique.
:
: tree,
: 或者
|
a********c
发帖数: 3657 | 10
null怎么实现b-tree啊。。。
难道if null ...else normal b-tree, 那得多sb啊
【在 m*******0 的大作中提到】
: 只有一个record的key是null的话，还是unique.
:
: tree,
: 或者
|
|
|
T********i
发帖数: 2416 | 11 不能不把null value当value好吧？
Value能在内部，在逻辑上比较大小就好。
谁说B tree不能index null的？
【在 a********c 的大作中提到】
:
: null怎么实现b-tree啊。。。
: 难道if null ...else normal b-tree, 那得多sb啊
|
w***g
发帖数: 5958 | 12 我就服老魏能下沉到代码细节里。
【在 T********i 的大作中提到】
: 比如SQLITE。
: CREATE TABLE sometable(Id INTEGER PRIMARY KEY)
: 简单吧？就是一个整数数组。而且是PRIMARY KEY
: 现在：
: SELECT MAX(ID) from sometable
: 50万数竟然将近一分钟！不就是二叉树么？竟然是O(n)，而不是O(Log(n))
: 上网查是没结果的！只能试
: CREATE TABLE sometable(Id INTEGER PRIMARY KEY NOT NULL)
: 这次只要5秒钟了！
: 问题是，PRIMARY KEY就隐含NOT NULL啊！所有教科书都是这么讲！
|
g****t
发帖数: 31659 | 13 有null, worst cast的select的复杂度就是o(n)吧？
所以SQLite的实现没啥问题。
: 我就服老魏能下沉到代码细节里。
【在 w***g 的大作中提到】
: 我就服老魏能下沉到代码细节里。
|
g****t
发帖数: 31659 | 14 我没细想。但是我认为：
有null，不管你怎么整。Worst case不可能是log的。必然要scan table。
除非你改一套自己的null的定义，以及在上面的代数与或非律。
例如Null == Null 一般是false。所以各种改造目测是很难的。
改造完了估计也没大用。别人还得弄个null2。
: 不能不把null value当value好吧？
: Value能在内部，在逻辑上比较大小就好。
: 谁说B tree不能index null的？
【在 T********i 的大作中提到】
: 不能不把null value当value好吧？
: Value能在内部，在逻辑上比较大小就好。
: 谁说B tree不能index null的？
|
T********i
发帖数: 2416 | 15 需要想么？有没有null，只要有index，必然是log(n)。period。
index里null和null比较是相等的。这是SQL spec规定的。index有index的规矩。只要
比较结果是稳定的就好。这才是应该有的逻辑。
【在 g****t 的大作中提到】
: 我没细想。但是我认为：
: 有null，不管你怎么整。Worst case不可能是log的。必然要scan table。
: 除非你改一套自己的null的定义，以及在上面的代数与或非律。
: 例如Null == Null 一般是false。所以各种改造目测是很难的。
: 改造完了估计也没大用。别人还得弄个null2。
:
:
: 不能不把null value当value好吧？
:
: Value能在内部，在逻辑上比较大小就好。
:
: 谁说B tree不能index null的？
:
|
T********i
发帖数: 2416 | 16 测试机器，几百M的log。重启动发现log get min/max要2分钟，不是一下子就发现了么？
【在 w***g 的大作中提到】
: 我就服老魏能下沉到代码细节里。
|
T********i
发帖数: 2416 | 17 我现在希望偶尔分享一下这些年来一些有趣的事情。。。 |
n******t
发帖数: 4406 | 18 sql 的標準就是非常貼近人思維的語言，導致這個東西100個數據庫有100種實現，想要
普遍
適用的性能指標幾乎不可能。select max min這個事情，postgres就沒有這個問題。
當然好處也是有的，就是所有地方都在用，經久不衰。我說了，30年來，不管你是who
，學點sql都可以養一大家人沒問題。
【在 T********i 的大作中提到】
: 比如SQLITE。
: CREATE TABLE sometable(Id INTEGER PRIMARY KEY)
: 简单吧？就是一个整数数组。而且是PRIMARY KEY
: 现在：
: SELECT MAX(ID) from sometable
: 50万数竟然将近一分钟！不就是二叉树么？竟然是O(n)，而不是O(Log(n))
: 上网查是没结果的！只能试
: CREATE TABLE sometable(Id INTEGER PRIMARY KEY NOT NULL)
: 这次只要5秒钟了！
: 问题是，PRIMARY KEY就隐含NOT NULL啊！所有教科书都是这么讲！
|
g****t
发帖数: 31659 | 19 我之前贴过吧？SQL的null实际上是个三值逻辑问题。
要是follow下面这些Null的规定，我认为是写不出o(log n)的select的。
https://modern-sql.com/concept/three-valued-logic
所以SQLite的select实现没硬伤。当然你可以说语法不便什么的。
: 需要想么？有没有null，只要有index，必然是log(n)。period。
: index里null和null比较是相等的。这是SQL spec规定的。index有index
的规矩
。只要
: 比较结果是稳定的就好。这才是应该有的逻辑。
【在 T********i 的大作中提到】
: 我现在希望偶尔分享一下这些年来一些有趣的事情。。。
|
g****t
发帖数: 31659 | 20 Postgres如果不写NoT Null,查找复杂度是o(n)还是o(log n)?
我怀疑都一样的。
: sql 的標準就是非常貼近人思維的語言，導致這個東西100個數據庫有100種實現
，想要
: 普遍
: 適用的性能指標幾乎不可能。select max min這個事情，postgres就沒有這個問
題。
: 當然好處也是有的，就是所有地方都在用，經久不衰。我說了，30年來，不管你
是who
: ，學點sql都可以養一大家人沒問題。
【在 n******t 的大作中提到】
: sql 的標準就是非常貼近人思維的語言，導致這個東西100個數據庫有100種實現，想要
: 普遍
: 適用的性能指標幾乎不可能。select max min這個事情，postgres就沒有這個問題。
: 當然好處也是有的，就是所有地方都在用，經久不衰。我說了，30年來，不管你是who
: ，學點sql都可以養一大家人沒問題。
|
|
|
T********i
发帖数: 2416 | 21 Index有index的比较规矩。
SQLite considers NULL values to be smaller than all other values. Hence NULL
values always appear at the beginning of an ASC index and at the end of a
DESC index.
【在 g****t 的大作中提到】
: 我之前贴过吧？SQL的null实际上是个三值逻辑问题。
: 要是follow下面这些Null的规定，我认为是写不出o(log n)的select的。
: https://modern-sql.com/concept/three-valued-logic
: 所以SQLite的select实现没硬伤。当然你可以说语法不便什么的。
:
:
: 需要想么？有没有null，只要有index，必然是log(n)。period。
:
: index里null和null比较是相等的。这是SQL spec规定的。index有index
: 的规矩
: 。只要
:
: 比较结果是稳定的就好。这才是应该有的逻辑。
|
w***g
发帖数: 5958 | 22 你自己干了当然能发现。现在公司都是打嘴炮的多干事情的少。
我这阵子在做一个业务数据分析的事情，在一个傻逼greenplum数据库上搞。
后来我的做法是把数据导到本地磁盘用python/C++分析。SQL写算法太反人性了。
谁特么也不是天天在研究数据库系统内部编程的，如果有上万行SQL代码，
出个什么问题太容易了。我们项目的前身就是全SQL倒腾数据，目前深陷泥潭。
min/max两分钟这种事情，junior programmer根本没有时间代价的概念。这种
性能炸弹混杂在一堆代码里面，根本清不干净。
么？
【在 T********i 的大作中提到】
: 测试机器，几百M的log。重启动发现log get min/max要2分钟，不是一下子就发现了么？
|
g****t
发帖数: 31659 | 23 那是不是Max()这个函数不认null比别的小这个规定？不然这个o(n)的root cause是啥
呢？
程序员错误的可能性不是不存在。但是这么明显的问题，确实很难相信没人发现。
: Index有index的比较规矩。
: SQLite considers NULL values to be smaller than all other values.
Hence NULL
: values always appear at the beginning of an ASC index and at the end
of a
: DESC index.
【在 T********i 的大作中提到】
: Index有index的比较规矩。
: SQLite considers NULL values to be smaller than all other values. Hence NULL
: values always appear at the beginning of an ASC index and at the end of a
: DESC index.
|
g****t
发帖数: 31659 | 24 找到了：
First, the MAX function ignores NULL values.
https://www.sqlitetutorial.net/sqlite-max/
可能根本原因就是MAX函数。
: 那是不是Max()这个函数不认null比别的小这个规定？不然这个o(n)的root
cause是啥
: 呢？
: 程序员错误的可能性不是不存在。但是这么明显的问题，确实很难相信没人发现。
: Hence NULL
: of a
【在 g****t 的大作中提到】
: 那是不是Max()这个函数不认null比别的小这个规定？不然这个o(n)的root cause是啥
: 呢？
: 程序员错误的可能性不是不存在。但是这么明显的问题，确实很难相信没人发现。
:
:
: Index有index的比较规矩。
:
: SQLite considers NULL values to be smaller than all other values.
: Hence NULL
:
: values always appear at the beginning of an ASC index and at the end
: of a
:
: DESC index.
|
T********i
发帖数: 2416 | 25 谁TM知道Sqlite咋实现的？
我这边手头7.7M源代码，你要去分析么？
有一点我是知道的，这个问题至少你牵狗是搜不到的。
end
【在 g****t 的大作中提到】
: 那是不是Max()这个函数不认null比别的小这个规定？不然这个o(n)的root cause是啥
: 呢？
: 程序员错误的可能性不是不存在。但是这么明显的问题，确实很难相信没人发现。
:
:
: Index有index的比较规矩。
:
: SQLite considers NULL values to be smaller than all other values.
: Hence NULL
:
: values always appear at the beginning of an ASC index and at the end
: of a
:
: DESC index.
|
T********i
发帖数: 2416 | 26 根本原因是他们优化算法错了。
没有Design by contract。
现。
【在 g****t 的大作中提到】
: 找到了：
: First, the MAX function ignores NULL values.
: https://www.sqlitetutorial.net/sqlite-max/
: 可能根本原因就是MAX函数。
:
:
: 那是不是Max()这个函数不认null比别的小这个规定？不然这个o(n)的root
: cause是啥
:
: 呢？
:
: 程序员错误的可能性不是不存在。但是这么明显的问题，确实很难相信没人发现。
:
: Hence NULL
|
T********i
发帖数: 2416 | 27 LOL。变身数据库码工了。这算不算被社会slow down了？
【在 w***g 的大作中提到】
: 你自己干了当然能发现。现在公司都是打嘴炮的多干事情的少。
: 我这阵子在做一个业务数据分析的事情，在一个傻逼greenplum数据库上搞。
: 后来我的做法是把数据导到本地磁盘用python/C++分析。SQL写算法太反人性了。
: 谁特么也不是天天在研究数据库系统内部编程的，如果有上万行SQL代码，
: 出个什么问题太容易了。我们项目的前身就是全SQL倒腾数据，目前深陷泥潭。
: min/max两分钟这种事情，junior programmer根本没有时间代价的概念。这种
: 性能炸弹混杂在一堆代码里面，根本清不干净。
:
: 么？
|
w***g
发帖数: 5958 | 28 我现在简直是在泥地里打滚，写特别特别世俗的代码，完全跟不上时代
节奏了。为了赚点钱不容易，不知道还能蹦达几天。
这两天正在苦苦顶着压力，不允许他们往设计里加入distributed
transaction的东西。麻痹的那批人因为最后锅不在自己背上想偷懒
设计的时候给我糊弄过去，调用我的算法时想让我自己去第三方取参数。
要是第三方服务器一牵扯进来，我特么数据一致性根本就没办法保证。
线上项目基本上都是千疮百孔。我估计最后也是同流合污。毕竟
写程序就是写程序，总不能把命搭进去。我现在已经不喜欢写程序了。
【在 T********i 的大作中提到】
: LOL。变身数据库码工了。这算不算被社会slow down了？
|
g****t
发帖数: 31659 | 29 我查了下，postgreSQL 的max也是ignore Null的。回头我建个表测一下。
: 根本原因是他们优化算法错了。
: 没有Design by contract。
: 现。
【在 T********i 的大作中提到】
: LOL。变身数据库码工了。这算不算被社会slow down了？
|
w********m
发帖数: 1137 | 30 有意思
null的primary key是怎么建b-tree的 |
|
|
m**e
发帖数: 12 | 31 你太抬举楼主了，他要是懂b-tree, 还会问这种傻叉的问题吗？
【在 w********m 的大作中提到】
: 有意思
: null的primary key是怎么建b-tree的
|
T********i
发帖数: 2416 | 32 请你自重。我这个帖子里回帖的牛人不少，撒泼打滚是你自己不好看。
当然了，公开论坛，你又蒙脸发帖，谁也不能把你咋样。这个论坛上华人各种无耻嘴脸
不胜枚举，多你一个不多，少你一个不少。
【在 m**e 的大作中提到】
: 你太抬举楼主了，他要是懂b-tree, 还会问这种傻叉的问题吗？
|
y****w
发帖数: 3747 | 33 有没有查一下sqlite到底有没有建立索引？ 考虑到sqlite是个玩具级实现，有可能在
这种矛盾情况下它直接忽略了这部分。 另外就是看下执行计划。
【在 T********i 的大作中提到】
: 比如SQLITE。
: CREATE TABLE sometable(Id INTEGER PRIMARY KEY)
: 简单吧？就是一个整数数组。而且是PRIMARY KEY
: 现在：
: SELECT MAX(ID) from sometable
: 50万数竟然将近一分钟！不就是二叉树么？竟然是O(n)，而不是O(Log(n))
: 上网查是没结果的！只能试
: CREATE TABLE sometable(Id INTEGER PRIMARY KEY NOT NULL)
: 这次只要5秒钟了！
: 问题是，PRIMARY KEY就隐含NOT NULL啊！所有教科书都是这么讲！
|
y****w
发帖数: 3747 | 34 这个应该不会。 id上的index需要allow reverse scan或类似。
-------------
SELECT MAX(ID)，MIN(ID) from sometable
不能被优化，是所有数据库的通病！你不能想象优化这个有多难！结果是分开运行10秒
钟，放到一个query 2分钟！ |
y****w
发帖数: 3747 | 35 刚装了下sqlite3实操了一下，没重现这个问题。 max.min同时也没毛病。 老魏你估计
是遇到特定版本上的bug了。
另外sqlite很操蛋啊，PK居然不算index? index_info啥的查不出来，居然只能看这么
个鬼定义。
sqlite> PRAGMA table_info('sometable');
0|Id|INTEGER|0||1
sqlite>
# 填数据 最后大概265万行
2035 while true; do maxx=$(echo "select max(id) from sometable;" | sqlite3
my.db); echo "insert into sometable select id+$maxx from sometable;" |
sqlite3 my.db; echo "select count(*) from sometable;" | sqlite3 my.db; done
[email protected]:~/tmp# time echo "select max(id),min(id) from sometable;" | sqlite3
my.db
2645760|1
real 0m0.286s
user 0m0.230s
sys 0m0.057s
-----
sqlite> CREATE TABLE sometable2(Id INTEGER PRIMARY KEY);
sqlite>
sqlite> insert into sometable2 select * from sometable order by random();
sqlite> select count(*) from sometable2;
2645504
sqlite>
sqlite> ^C
sqlite>
sqlite>
[email protected]:~/tmp#
[email protected]:~/tmp#
[email protected]:~/tmp# time echo "select max(id),min(id) from sometable2;" | sqlite3
my.db
2645760|1
real 0m0.330s
user 0m0.265s
sys 0m0.066s |
y****w
发帖数: 3747 | 36 有些数据库可以在sql查询中指定nulls first or nulls last
NULL
【在 T********i 的大作中提到】
: Index有index的比较规矩。
: SQLite considers NULL values to be smaller than all other values. Hence NULL
: values always appear at the beginning of an ASC index and at the end of a
: DESC index.
|
T********i
发帖数: 2416 | 37 赞实干精神！
试试这个。我当然没只创建一个数组。没有意义。
CREATE TABLE IF NOT EXISTS Logs (Id INTEGER PRIMARY KEY, Data BLOB)
另外回答你SQLITE primary key包含null的问题。其实是他们开始的一个bug，等发现
的时候，已经不能改了，因为会break已有的用户。
index null的问题，已经讨论了。本来就没问题。
至于insert，SQLITE的规则是NULL和NULL不等。翻译成人话就是可以insert无穷多null
as primary key value。其实对select性能没影响。因为index照样work O(log n)。
sqlite3
【在 y****w 的大作中提到】
: 刚装了下sqlite3实操了一下，没重现这个问题。 max.min同时也没毛病。 老魏你估计
: 是遇到特定版本上的bug了。
: 另外sqlite很操蛋啊，PK居然不算index? index_info啥的查不出来，居然只能看这么
: 个鬼定义。
: sqlite> PRAGMA table_info('sometable');
: 0|Id|INTEGER|0||1
: sqlite>
: # 填数据 最后大概265万行
: 2035 while true; do maxx=$(echo "select max(id) from sometable;" | sqlite3
: my.db); echo "insert into sometable select id+$maxx from sometable;" |
|
c*******v
发帖数: 2599 | 38 贊實幹。回頭我也測一下。
sqlite3
【在 y****w 的大作中提到】
: 刚装了下sqlite3实操了一下，没重现这个问题。 max.min同时也没毛病。 老魏你估计
: 是遇到特定版本上的bug了。
: 另外sqlite很操蛋啊，PK居然不算index? index_info啥的查不出来，居然只能看这么
: 个鬼定义。
: sqlite> PRAGMA table_info('sometable');
: 0|Id|INTEGER|0||1
: sqlite>
: # 填数据 最后大概265万行
: 2035 while true; do maxx=$(echo "select max(id) from sometable;" | sqlite3
: my.db); echo "insert into sometable select id+$maxx from sometable;" |
|
r****t
发帖数: 10904 | 39 小公司肯定开始都有特别世俗的代码，好歹兄的还是赚到了钱的，
核心算法守好，世俗部分能用第三方服务就上吧，成本反正不在engineering这边。
【在 w***g 的大作中提到】
: 我现在简直是在泥地里打滚，写特别特别世俗的代码，完全跟不上时代
: 节奏了。为了赚点钱不容易，不知道还能蹦达几天。
: 这两天正在苦苦顶着压力，不允许他们往设计里加入distributed
: transaction的东西。麻痹的那批人因为最后锅不在自己背上想偷懒
: 设计的时候给我糊弄过去，调用我的算法时想让我自己去第三方取参数。
: 要是第三方服务器一牵扯进来，我特么数据一致性根本就没办法保证。
: 线上项目基本上都是千疮百孔。我估计最后也是同流合污。毕竟
: 写程序就是写程序，总不能把命搭进去。我现在已经不喜欢写程序了。
|
