歡迎光臨, 訪客. 請先 登入註冊一個帳號.
四月 26, 2024, 04:51:47 上午
19595 文章 在 3865 主題 由 4580 會員
最新註冊會員: aa123aa1
LifeType 中文開發論壇  |  支援  |  使用與操作  |  關於多使用者PLOG所產生的UID « 上篇主題 下篇主題 »
頁: [1]
作者 主題: 關於多使用者PLOG所產生的UID  (閱讀 10650 次)
bibicall
版主
超級會員
*****
文章: 640


我是豬老大


檢視個人資料 個人網站
« 於: 三月 30, 2005, 12:44:30 下午 »

我在我的plog(0.32版)裡刪掉一個使用者
再重新新增一個使用者
結果UID變成不連續
假設我第一次新增的使用者的UID是10
刪掉之後重新新增UID卻是11

是因為資料庫的關係嗎?
我在資料庫裡也把USER 10的相關資料欄位都刪除了

可是新增後還是不連續?
 why?疑惑
已記錄

我的虛擬主機基本資料如下
Operating system: Linux
Apache version: 1.3.37
PHP version: 4.4.4
MySQL version: 4.1.21-standard
darkhero
初級會員
**
文章: 58


檢視個人資料 個人網站
« 回覆文章 #1 於: 三月 30, 2005, 01:27:58 下午 »

引用自: bibicall
我在我的plog(0.32版)裡刪掉一個使用者
再重新新增一個使用者
結果UID變成不連續
假設我第一次新增的使用者的UID是10
刪掉之後重新新增UID卻是11

是因為資料庫的關係嗎?
我在資料庫裡也把USER 10的相關資料欄位都刪除了

可是新增後還是不連續?
 why?疑惑


沒錯...正是資料庫的原因...

資料庫的 auto_increment 欄位會紀錄下一個 auto_increment 的 id 值.
而該值並不會因為你砍掉當時最大的 uid 值改變. 除非你將整個資料表重建 也就是全部清空,該值才會同時重設...

這樣做也是比較好的...

試想: 要是你砍掉一個人.而那個人已經建立的 blog , 寫過文章寫過資料...
而後來的人用了他的 uid , 那系統要如何判斷那篇文章以及哪個 blog 是屬於哪個 uid user的?...
難道讓後來新增的看到或沿用原來 uid 的資料是對於原使用者比較好嗎?....

當然.通常系統在刪除使用者的時候會同步刪掉所有的使用者資料跟文章..

如果你是想知道使用者人數...
也不是看 uid 值來判斷 , 而是應該 select count(uid) from user 這類的方式.
已記錄

markwu
系統管理員
超級會員
*****
文章: 3928


Mark Wu


檢視個人資料 個人網站
« 回覆文章 #2 於: 四月 01, 2005, 01:26:35 下午 »

bibicall:

Darkhero 講得很清楚了,就是這樣沒錯。一般的資料庫設計都不會刪除資料後,重新整理(命名) id 的,這很容易出錯喔!

Mark
已記錄

TomexOu
一般會員
***
文章: 117



檢視個人資料
« 回覆文章 #3 於: 四月 01, 2005, 11:41:30 下午 »

auto increatment欄位雖好,但跳了一號就會覺得怪怪的
我了解原po的心境。

這種identity欄位變動並不方便,尤其轉移匯出數據時很危險
要一直受其制約。

當然,它在程式寫作及效能上(index)很有用
因為我db實務上,會有 serial_id及 table_id
前者給程式看的,後者給人看的。
已記錄

我的LifeType測試環境:
Win2003 R2 Enterprise/IE7.0/XAMPP with Apache 2.2.6 + PHP 5.2.4 + MySQL 5.0.45 /LifeType 1.2.5/GD2.0/Grey Template
Dabu網誌
markwu
系統管理員
超級會員
*****
文章: 3928


Mark Wu


檢視個人資料 個人網站
« 回覆文章 #4 於: 四月 02, 2005, 11:52:51 下午 »

其實以 blog 的 DB 設計還算簡單!在ERP或財物系統中,資料是絕不可能刪除的啦,只能 把 delete flag 設為  "on" 或是用 roll back (undo) 的方式來做刪除,否則資料會大亂。

Mark
已記錄

頁: [1]
LifeType 中文開發論壇  |  支援  |  使用與操作  |  關於多使用者PLOG所產生的UID « 上篇主題 下篇主題 »
    前往: