SQLite 資料表怎麼設計比較不會後悔：從文章站常見欄位開始
很多人第一次做 Flask 內容站時，資料表設計通常都很直覺，例如先放 title、author、content、created_at，站能跑就先上。這完全合理，因為第一步本來就是先讓網站動起來。但如果你完全不想一下資料表未來可能會怎麼長，之後加功能時就很容易開始後悔。 先講一個很重要的觀念：資料表設計不需要一開始就完美，但最好一開始就保...
很多人第一次做 Flask 內容站時，資料表設計通常都很直覺，例如先放 `title`、`author`、`content`、`created_at`，站能跑就先上。這完全合理，因為第一步本來就是先讓網站動起來。但如果你完全不想一下資料表未來可能會怎麼長，之後加功能時就很容易開始後悔。
先講一個很重要的觀念：資料表設計不需要一開始就完美，但最好一開始就保留一些明顯會用到的欄位空間。對文章站來說，最常見的欄位通常包括：
id
title
slug
author
content
excerpt
status
created_at
updated_at這裡面最容易被忽略的是 `slug`、`excerpt`、`status` 和 `updated_at`。
`slug` 代表比較穩定、可讀的網址片段。如果你一直只用文章 ID 當網址，例如 `/post/1`、`/post/2`，當然也能跑，但之後如果你想讓網址更清楚、更適合 SEO，slug 往往會很有幫助。
`excerpt` 則是摘要。有些站會直接從文章內容前面截一段文字當摘要，這在一開始沒問題，但等你開始在意首頁卡片、SEO description、社群分享摘要時，能不能有一段手動控制的摘要，差很多。
`status` 通常用來區分文章是草稿還是已發布。如果你之後想讓後台先存草稿、確認內容後再公開，這個欄位就很重要。
`updated_at` 則能幫你知道文章最後一次修改時間。這對內容維護、排序、sitemap、SEO 都有幫助。
另外，當文章站開始成長後，分類與標籤通常也會進來。這時候就不只是單一 `posts` 資料表，而可能會開始有 `categories`、`tags`、`post_tags` 這類結構。也就是說，資料表設計本身會反映你網站的功能階段。
所以比較務實的做法通常是：第一版先做小而完整，但不要把欄位設計得過度僵硬。至少把未來最有機會用到的欄位概念想過一輪，這樣等到你要補分類、SEO、草稿、搜尋時，資料層比較不會整個重來。
資料表設計真正的重點，不是一次設計到最終版，而是讓網站從小站長成內容站的過程中，不會因為一開始過度簡化而每次加功能都要痛苦搬家。