はじめに

今までに出会った、実際にあったデータベースの使い方を列挙してみます。

SQLアンチパターンでも拾いきれない、さすがに想定外の使い方ではないかと思われます。

良い子の皆様にはショッキングな内容と想像されます。
心の弱い方はそっと閉じてください。

正規化されていない

正規化されておらず、同じ値があちらこちらにあると、更新処理が無駄に長大なトランザクションになります。
仕様を把握しにくくなり、バグの温床になります。

大昔は、パフォーマンスのためにあえて正規化を崩す（テーブル結合せずに値をとれるようにする）という手段もありましたが、今でも通用するでしょうか？

テーブルに主キーがないと、更新対象行を一意に特定できているのかどうかわかりません。
テーブルに主キーがないと、プログラムから使おうとしたとき、面倒な手数が増えます。

これはSQLアンチパターンに掲載ありましたね。
外部キーなくして、なんのためのRDBMSかという。

インデックスがないと、全行検索になってしまいます。

連番が欲しいのならば、データベースの機能を使ったほうがよいです。
単にユニークな値が欲しいのなら、プログラム側からGUIDを格納してあげたほうが幸せです。

どうしてもというのであればフォーマンスを考慮してください。デッドロックにも注意です。

intとかbitとか、用途に合わせて型を選ぶべきです。

大抵はO/Rマッパを使うのでしょうから、データ型はコードから生成してあげたほうがよいです。

パースしないと日付/日時として扱えないのは不便過ぎます。
比較も難しいです。
タイムゾーンへの対応も難しいです。

一周回って、逆にデータベースの日付型が貧弱過ぎるから自前でやる、というのはありです。

新規構築するシステムでUnicodeを選ばない理由はありません。

鯖の異体字 鯖󠄄 を保存したくなるシーンはないでしょうか？

長さ制限にひっかからないのであれば、無理に略さなくてもよいですよ。
パッと見で意味を汲み取れません。

とにかく全てのテーブルに作成日/更新日列をつけます。
さらに作成者/更新者、作成プログラム/更新プログラムのような列がつけられることもあります。

テーブルの趣旨にあわせて、その列が必要かどうか判断してください。

監査/トレース目的なら、また別の方法を検討したほうがよいです。

データベースに負荷をかけるような処理は、なるべく控えたほうがよいです。
増強が難しくなります。