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();
});
}
小白的瞎擔心？？
已邀請的邦友 {{ invite_list.length }}/5
對於 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。
也許 Laravel 的開發者是這樣想的吧?
不過實務上要到這麼多也不容易,
而且會有這麼大量資料的通常可能不適合用數字來當主鍵,
我覺得會有安全性的考量.
我個人的規矩是，【能省則省】，就算空間很充裕，也沒必要無故浪費。
一塊錢掉在地上，沒什麼大不了，您撿是不撿？
（註：如果您不撿的話，請通知我，我去撿。）
我個人也猜想：Laravel 的開發者因為要滿足所的有 Laravel 用戶，又得要貼心地減少開發者需寫的代碼，且又要讓程式盡量簡潔優美，所以使用bigInteger就剛好滿足這一切。
以上想法讓我必須抉擇：
1、懶惰法：不管他空間，現代主機都很強大。(省事又不會出錯)
2、嚴謹法：能用tinyint不用int、能用int不用bigint、...不僅省空間，效能上也會積少成多地自動提升...。(個人比較頃向)
但就因為我個人所學不夠完整，所以感到疑惑，才想說上來請教前輩們的經驗意見，想說也可能會有許多初學者會同樣面臨這些疑惑，因此就不怕見笑地提出這種很基礎的問題。
您可以反過來設想一下，為什麼 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。
其實我沒特別去思考這個問題,
不過都用BigInteger好像也還好...
新的一年的第一篇。
瞎擔心??其實並不是。
基本上來說，會去思考這樣問題的人，一定第一優先考量的是空間佔用問題及記憶體使用量問題。
不過有時自已問問自已一下，真的是這樣嘛?
今天是因為 Laravel 預設值是用 bigInteger。
這樣的設定已經多久了，很久了。
如果有真心研究Laravel的人，他的設計規劃是採用安全不出問題的做法偏向。
但不考量效能及用量的問題。
不能說他們這樣的想法是錯的。因為他也只是一個工具。效能及用量的考量是要由工程師去處理的。
所以，我們再拉回來你原來的問題。
integer 與 bigInteger 有差??
是的，有差。但要如何使用決定權在你自已。你自行評估。
沒有說用誰比較好比較差。只有適合與不適合。
以前處理過資料內容需要依據『時間戳』(timestamp)來建置，那時就只好用 bigInteger 來建流水號 ! 雖然當初是用 Java Spring 來建置網站，不過我猜 Laravel 預設 bigInteger 是因為商業網站直接採用 timestamp 來做流水號不在少數吧 ! 其實版上技術問答區吸引我的地方就是『雖然大家開發的語言不一定相同，不過解決問題的手段卻不盡相同。』
其實，我是曾經有流水號用int不夠用的情況過了。
遊戲的記錄。一天最少有100多萬筆記錄，最高記錄是1000多萬筆。
這樣子跑一年多就爆了。
當時還是菜鳥，還不懂bigint。是採用另建一張表重新記錄處理。(其實流水號不重要)
iThome鐵人賽
看影片追技術