iT邦幫忙

1

請教一下大大們!關於Laravel migration 文件中預設為 $table->bigIncrements('id') ,產生的糾結該如何選擇?

Laravel 使用數據型態 biginteger 為自動預設 ,其來有自嗎?
EX:2014_10_12_000000_create_users_table.php 中 $table->bigIncrements('id');

public function up()
    {
        Schema::create('users', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->timestamps();
        });
    }

我自己評估我的資料量id 頂多10位數 就已經綽綽有餘,請教一!下我若改成如下:
使用 integer 請問適當嗎? 有較省空間嗎? 還是只是瞎操心,使用bigInteger 其實也用不了多少空間的,尤其現在的主機容量都很大。

public function up()
    {
        Schema::create('users', function (Blueprint $table) {
            $table->increments('id');
            $table->timestamps();
        });
    }

小白的瞎擔心??

自覺是十分好笑的問題,不知道眾高手大大們剛初學的時候,有過這樣"想問又怕見笑"的心情嗎?
經常啊,不過就問吧。反正笑笑也就過了,懂了才是真的。
1
f107110126
iT邦新手 5 級 ‧ 2020-01-09 02:22:43
最佳解答

對於 increments, bigIncrements 這兩種型態的詳細特性就不在這邊解說了,請情 Google。

以 db_drive 為 mysql 來說,大約是這樣的:
$table->increments('id')
==>對應 SQL create table 時: id int unsigned not null auto_increment
$table->bigIncrements('id')
==>對應 SQ create table 時L: id bigint unsigned not null auto_increment

在 mysql 中 int 與 bigint 的最大差異在於儲存量與儲存所暫用的空間,實際使用案例會不會遇到 int 的儲存上限,這點可以做為考量的指標。

過去儲存空間很有限的時候,的確需要考慮資源問題。但現在硬碟都用 T 在算的,很少人會去計較那不到 kB 的差異。

看更多先前的回應...收起先前的回應...

我是否可以說:現在用法可以bigInteger直接取代integer,反正空間差異還算可以接受,而好處是不需要擔心萬一有天不小心資料多到超過4294967295。

小魚 iT邦大師 1 級 ‧ 2020-01-09 08:29:35 檢舉

也許 Laravel 的開發者是這樣想的吧?
不過實務上要到這麼多也不容易,
而且會有這麼大量資料的通常可能不適合用數字來當主鍵,
我覺得會有安全性的考量.

ckp6250 iT邦新手 2 級 ‧ 2020-01-09 08:49:57 檢舉

我個人的規矩是,【能省則省】,就算空間很充裕,也沒必要無故浪費。
一塊錢掉在地上,沒什麼大不了,您撿是不撿?
(註:如果您不撿的話,請通知我,我去撿。)

我個人也猜想:Laravel 的開發者因為要滿足所的有 Laravel 用戶,又得要貼心地減少開發者需寫的代碼,且又要讓程式盡量簡潔優美,所以使用bigInteger就剛好滿足這一切。
以上想法讓我必須抉擇:

1、懶惰法:不管他空間,現代主機都很強大。(省事又不會出錯)
2、嚴謹法:能用tinyint不用int、能用int不用bigint、...不僅省空間,效能上也會積少成多地自動提升...。(個人比較頃向)

但就因為我個人所學不夠完整,所以感到疑惑,才想說上來請教前輩們的經驗意見,想說也可能會有許多初學者會同樣面臨這些疑惑,因此就不怕見笑地提出這種很基礎的問題。

ckp6250 iT邦新手 2 級 ‧ 2020-01-09 09:31:07 檢舉

  您可以反過來設想一下,為什麼 mysql 要搞那麼多欄位型態,又是 tinyint 又是 int , bigint.....

  它幹嘛這麼費勁?甘脆只留一種 bigint 豈不更省事?

  凡存在必合理。

如果省1元,卻損失了10萬……你是要撿1元,還是賺10萬?
時代在變,環境和硬體也都在改變。
腦袋瓜就必須跟著改變。
即變溫故而知新,也不是全然守著舊理而不曉得權變。
當你在撿那1元時,世界並不會因此繞著你而轉。
錢還是人家賺的比較多。
再者,我掉了1元,但是我掉在石門老梅綠石槽的海邊……也要撿嗎?
成本怎麼計算?

來,問一個大家的問題。
我們都知道phpmyadmin在建構表時。其欄位類型的預設值都是int。
如果說今天phpmyadmin的預設欄位不是int而是bigint。
有多少人會去變動它呢??

我相信,至少有一半以上的人,除非是要更換成字元類型。
要不然是沒人會去變動他的。

會這些說的原因也不外乎就是「懶」或是「沒差」
只有真正思考到流水位元會爆的人才會思考這個問題。

只是你問的出發點不對了。你是問int跟bigint哪個好。
這樣問就不對的。因為這兩個類型都有其必要的特性。
就像是你如果是要存字元。你絕對不會問varchar和int哪個比較好。
(如果真這樣問的話,我想你因該會被打到不知道去哪了)

簡單來說,要用bigint還是int。決定權再於你。不過建議你不要用 4294967295 來當成最大值會比較好。在某些情況下,數值存入的值會被視為有符號的。所以其int的最大值最好還是視為可用值只到2147483647。

一般來說,像記錄式的的確有其機率會超過。我就會使用bignit。
其餘大多數還是用int處理。但平常我有去注意到清除問題。
你也可以先用int。當碰到不足的情況下,再改成bigint。

0
小魚
iT邦大師 1 級 ‧ 2020-01-08 22:28:37

其實我沒特別去思考這個問題,
不過都用BigInteger好像也還好...

嗯!我也這樣想只是不確定不放心,謝謝。

小魚 iT邦大師 1 級 ‧ 2020-01-09 12:31:00 檢舉

個人淺見,
如果你剛開始接觸資料庫,
其實先考慮能不能動,
效能的東西就放後面吧,
速度的快慢還是跟資料量大小有關,
最多就是多佔一點空間而已.

如果你資料庫已經寫一陣子,
想要進階了,
可以開始規劃最適合的欄位跟索引等等的了.

1
浩瀚星空
iT邦大師 1 級 ‧ 2020-01-09 09:48:44

新的一年的第一篇。

瞎擔心??其實並不是。
基本上來說,會去思考這樣問題的人,一定第一優先考量的是空間佔用問題及記憶體使用量問題。
不過有時自已問問自已一下,真的是這樣嘛?

今天是因為 Laravel 預設值是用 bigInteger。
這樣的設定已經多久了,很久了。

如果有真心研究Laravel的人,他的設計規劃是採用安全不出問題的做法偏向。
但不考量效能及用量的問題。
不能說他們這樣的想法是錯的。因為他也只是一個工具。效能及用量的考量是要由工程師去處理的。

所以,我們再拉回來你原來的問題。

integer 與 bigInteger 有差??
是的,有差。但要如何使用決定權在你自已。你自行評估。
沒有說用誰比較好比較差。只有適合與不適合。

以前處理過資料內容需要依據『時間戳』(timestamp)來建置,那時就只好用 bigInteger 來建流水號 ! 雖然當初是用 Java Spring 來建置網站,不過我猜 Laravel 預設 bigInteger 是因為商業網站直接採用 timestamp 來做流水號不在少數吧 ! 其實版上技術問答區吸引我的地方就是『雖然大家開發的語言不一定相同,不過解決問題的手段卻不盡相同。』/images/emoticon/emoticon07.gif

其實,我是曾經有流水號用int不夠用的情況過了。
遊戲的記錄。一天最少有100多萬筆記錄,最高記錄是1000多萬筆。
這樣子跑一年多就爆了。

當時還是菜鳥,還不懂bigint。是採用另建一張表重新記錄處理。(其實流水號不重要)

我要發表回答

立即登入回答