SQL 的 ORDER BY 會執行資料的重新排序，然後輸出給上層查詢或輸出給用戶端，開發實務上 ORDER BY 的情況非常常見，就跟呼吸一樣自然，但是 ORDER BY 對一個設計不良的資料庫可以說是一個大災難，因為它排序的對象是結果集，若結果集愈大，ORDER BY 會拖慢效能，但適當的設計可以減少 ORDER BY 對效能的損耗。
在資料庫設計上，PK (主鍵) 一直都是設計的重點之一，但主鍵使用的資料型態有可能直接或間接影響到資料庫的存取效能，然而技術是會演進的，30年前可能不行的作法在30年後的今天是否仍然不適用? 似乎有待商榷。
在資料表結構 (table schema) 中，每個欄位除了基本的欄位名稱、型態、大小等資料外，有一個有趣的欄位很特別，就是是否允許 NULL，NULL 這個東西對程式設計師來說是又愛又恨，有時會被它搞得嫑嫑的，但是它有時卻又是一個有必要的存在。
如果可以由資料庫本身去做彈性設計的話，對於物件使用 ORM 以及擴充上會有正面幫助，物件可以不受物件既有資料表欄位的限制，即可由物件自己去決定會多或會少哪些資料，而資料庫依照物件的要求做出反應，即可確保物件的高彈性，又可以簡化資料表的設計。這個方法即為 Profile 架構。