理智檢查：漂浮爲主鍵？

我正在使用舊的sql server 2000數據庫，將它的一些信息與正在構建的新應用程序混合在一起。我注意到幾個表中的一些主鍵是浮點數，而不是任何類型的整數。它們不是外鍵，都是獨一無二的。我無法想出任何人想要使其唯一的主鍵ID浮動的任何理由，但我不是任何方式的SQL專家。所以我想我問的是誰設計這個相當廣泛的數據庫知道我不知道的東西？理智檢查：漂浮爲主鍵？

來源

2009-07-09 Graham Conzett

我相信你的直覺在這裏是100％正確的;漂浮使壞鑰匙。 – 2009-07-09 17:36:39

我目前正在使用一個相當大的會計軟件包，其中每個350+表都有一個主鍵FLOAT（53）。所有的實際值都是整數，系統會嚴格檢查它們的確是（有特殊功能可以完成所有遞增工作）。

我確實在想這個設計，但我可以理解爲什麼選擇它並給它一些學分。一方面，系統足夠大，在一些表格中有十億條記錄。另一方面，這些主鍵必須易於從外部應用程序（如Excel或VB6）讀取，在這種情況下，您並不想使它們成爲BIGINT。

因此，浮動很好。

來源

2009-07-09 18:51:24 GSerg

它是一個NUMERIC（x，y）格式和一個IDENTITY嗎？如果是這樣，它可能是從舊版本的SQL Server升級。當天返回的IDENTITY只能是NUMERIC格式，而不是我們今天使用的常見INT。

否則，無法判斷浮點數是否適合作爲主鍵 - 這取決於您的域。這比較難以比較（IEEE INT比浮點效率更高），大多數人使用單調遞增的數字（IDENTITY），所以整數通常是人們真正想要的。

因爲它看起來像你存儲整數：

更直接地回答原來的問題：如果你存儲整數，使用整數數據類型。存儲和比較效率更高。

來源

2009-07-09 17:17:07

實際上，PK可以一直是INT，但是由於BIGINTs不存在，所以人們使用NUMERICs – zvolkov 2009-07-09 17:20:02

好的。我知道Sybase SQL Server - 永遠只支持NUMERICS，並且我認爲SQL Server的6.5以上版本繼承了這個限制 – 2009-07-09 17:27:46

我相信他們從一開始就使用SQL Server 2000，儘管我不是100％確定的。不過我要仔細檢查一下。 – 2009-07-09 17:41:40

花車有一個有趣的屬性：它總是可以在兩個其他人之間插入一個值，除了你用完比特的病態情況。它的缺點是代表性問題可能使您不能通過密鑰引用行;很難使兩個浮點值彼此相等。

來源

2009-07-09 17:23:57

我曾與一些在SQL Server數據庫中使用浮點數作爲PK的人一起工作。如果他堅持INT，他很擔心標識符的數字用完了。（在SQL Server上是32位）。他只是看着float的範圍，並沒有想到這個事實，不用擔心，由於精度有限，對於較大數字來說，那些地方並不在數字中。所以他的MAX（PK）+ 1.0的代碼在某些時候會返回一個等於MAX（PK）的數字。不好。我終於說服他不要爲將來的數據庫使用浮點代替主鍵。他在修理他正在研究的數據庫之前辭職。

要回答你的問題，「所以我想我要問的是，設計這個相當廣泛的數據庫的人知道我不知道嗎？」最有可能的是不！至少與選擇數據類型無關。

來源

2009-07-09 17:57:18

我一直在使用Cerner Millenium數據庫幾年（在它使用Oracle的封面下）。起初，我很驚訝地發現它使用浮點數作爲表格上的ID。然後我在我們的數據庫> 2^32中遇到了一個ID，並且我寫的查詢給出了錯誤的結果，因爲我錯誤地將它轉換爲INT，我意識到他們爲什麼要這樣做。我沒有發現任何上述反對在現實世界中使用浮動的說法，其中對於只需要鍵的數字「比2^32略大」，並且ID的值始終爲格式#### ##。0。（沒有人談論表單######。######。）的ID。但是現在我們將這些數據導入SQL Server倉庫，並且可以使用bigint，我們要去用bigint代替float。

來源

2013-11-06 18:21:46 ckapilla

FYI--存在的看着這個法子：

我在實時過程控制工作，正因爲如此，我的大部分行條目都是基於時間的，並且在高利率的非自動生成-ASCII機器。時間 - 這是我的用戶通常搜索的內容，而我的許多「用戶」實際上都是機器。因此，基於UTC的主鍵。

來源

2015-11-16 14:34:42 george

理智檢查：漂浮爲主鍵？

回答

相關問題