わからないことが二つあります。
0. データベースのテーブルのレコードに必ず必要になっているカラムの確認と存在する合理的な理由
- カラムの順番についての合理的な理由
の二つです。
1.についてですが、データベースのテーブルには必ず、以下のような3項目(レコードid,作成日,更新日)がほとんどのレコードに存在しますが、他にも何かいつも存在するカラム定義、もしくはとあるケースでは必須になってくるカラム定義はありますでしょうか?
SQL
1CREATE TABLE example{ 2 id int 3 ,~~~ 4 ,~~~ 5 ,created_at datetime 6 ,updated_at datetime 7};
また、これら3項目以外のカラムを付け加える場合の合理的な理由を教えてください。
2.についてですが、データベース定義書を作っている場合、必ず、作成日と更新日のカラムを末尾にしなくてはいけないのでスプレッドシートソフトでの項番の降り直しがめんどくさいです。
私は別にupdated_at(更新日)カラムの後ろに新しく追加されたカラムを記述しても問題ないと考えますし、CREATE TABLE文を作る時にもそれで問題ないと考えるのですが、何かカラムの順番について合理的な理由はあるのでしょうか?
詳しい方、よろしくお願いいたします。
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
回答6件
0
それは質問者さんの属する組織のルールとか、DB を使うアプリなどの仕様書などでそうすることに決めているからではないですか?
データベースのテーブルそのものに、その 3 つのフィールドが存在しなければならないとか、順序はこうしなければならないとかの「合理的な理由」というのはないはずです。
投稿2018/12/25 20:41
編集2018/12/25 20:44退会済みユーザー
総合スコア0
0
1.についてですが、データベースのテーブルには必ず、以下のような3項目(レコードid,作成日,更新日)がほとんどのレコードに存在しますが、他にも何かいつも存在するカラム定義、もしくはとあるケースでは必須になってくるカラム定義はありますでしょうか?
「データベースのテーブルには必ず、以下のような3項目(レコードid,作成日,更新日)がほとんどのレコードに存在しますが」は言い過ぎですが、フレームワークの機能的な制約や設計思想として存在することは結構あります。
何をもって合理的とするかは判断が分かれるところではありますが、
例えば「テーブル定義に一定のルールを持たせることにより、フレームワークのO/Rマッパーで提供される最低限の機能を全テーブル/モデルに確保する」というのは、テーブル単位/DB単位では合理的ではなくてもアプリケーション前提としては合理的であると思います。
フィールド個別のメリットや思想としては以下のような感じでしょうか。
(メリットや思想なので絶対的に合理的な理由にはなりませんが、それなりの
例えばIDについてはサロゲートキーという考え方に基づいて設定されますので調べてみてください。
更新日や作成日については、あると色々な面で便利なことが多いので「とりあえず」設定しておくと何かと便利です。
例えば、サービスを運用していく上で必要になったりであるとか(何らかの仕様やバグでいつの間にかデータが変わっていた際の調査のとっかかりにするとか、日時でデータをソート/抽出)、データに手軽にリビジョン機能を持たせることが出来るようになったりであるとか色々なケースがあります。
もちろんこれらは事前に運用まで含めて設計出来ればベストではあるのですが、あっても困るケースはほとんどないので形式的につけておいて運用や機能拡張の幅を確保しておくという感じでしょうか。
2のフィールドの順序については、ドキュメンテーションに関するポリシーだったり決まりだったりするだけでしょうが、「設計ルールとして強制されているフィールドを末尾に配置する」というのは、ミスを防ぐ意味や閲覧性を高める上でそれなりに有効なルールに思います。
投稿2018/12/25 22:19
総合スコア18706
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
データベース定義書を作っている場合、必ず、作成日と更新日のカラムを末尾にしなくてはいけないのでスプレッドシートソフトでの項番の降り直しがめんどくさいです。
私は別にupdated_at(更新日)カラムの後ろに新しく追加されたカラムを記述しても問題ないと考えますし、CREATE TABLE文を作る時にもそれで問題ないと考えるのですが、何かカラムの順番について合理的な理由はあるのでしょうか?
データベースという視点なら、質問についての合理的な理由などありません。
察するに、最新の定義状態をDBツールで出力して、メンテナンスされているということでしょうか。
そうであれば、先ず、CRATE TABLE文を並び替えてローカルで実行し、それから定義状態を出力すると楽になるのではないかと思います。
多分、行われているのは開発過程での作業で、本番にはメンテナンスした定義で再度作成するのではないでしょうか。
稼働後に、定義をメンテナンスするとしたら、並び替えなどすることは無いはずですから。
面倒な作業を行う為の理由付けを求めているなら、作業自体を改善する方法を考えた方が良いですね。
投稿2018/12/26 02:37
総合スコア25083
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
ベストアンサー
テーブルは大きく3種類の運用があります
- マスターテーブル
正規化により任意のコードから一意にレコードを選定する
- データテーブル
とにかくデータの塊
- 中間テーブル
データ間の関連性を保持する
当然それぞれ役割が違うため必要なカラムは異なります。
質問者さんの言うidとはおそらく主キーとなるレコードを特定するカラムです
これがないともし完全にデータが一致するレコードが複数存在した場合
参照・変更・削除することが困難になります。
ただマスターテーブルについては主キーがマスターデータを特定するコードになるケースがありますし
マスターに履歴を取る場合があればレコード間でコードがだぶる場合もあるのでやはり別途
主キーが必要になったりして、すべて同じ運用ができるわけではありません。
また作成日時・更新日時については、保守のためにはあった方がよいですが、必ずしも必要とは言えず
さらに言えば更新日時はカラム毎に保持する必要がある場合もあるのでこれも単純ではありません。
主キー、作成日時、カラム1データ、カラム1更新日時、カラム2データ、カラム2更新日時、・・・
その他よく利用されるものとしては以下のようなものがあります
- 論理削除フラグ
- 作成者、更新者
- 参照・更新・削除権限者(グループ)
ちなみにDBにおいてカラムの順番にはあまり意味がありません
逆に言えば昔は一度カラムの位置をきめるとあとから切り替えができなかったこともあるので
きちっとしないと気持ちが悪いという人は設計段階からかなり気をつける必要がありました
いまはそのあたりも柔軟になっているのでそれほど気にしなくてよいでしょうけど
作成日や更新日はユーザーが任意に修正するものではないので往々にして後ろに持っていかれる
ことが多いように感じます、それがまさに合理的な理由でしょう
そもそもテーブルの設計をそうそう変更することもないので、後ろにあって苦労するということは
ありません。もし気になるなら、まず設計自体を最初からちゃんとすることを心がけて下さい
投稿2018/12/26 01:02
編集2018/12/26 01:03総合スコア114505
0
1.データベースのテーブルのレコードに必ず必要になっているカラムの確認と存在する合理的な理由
ないです。要件・仕様・設計次第で必要なカラムは変化します。
idや更新日時、登録日時すら必要がない場合もあります。
OracleなどではROWIDといって自動で入る擬似列があり、そちらをIDの代用として使うこともあります(真のキーとも呼ばれているようです)
更新日時や登録日時はシステム側の都合で入れるものなので、登録や更新が発生しないもの、トレーサビリティが必要でないものには入れる必要はありません。
※フレームワークや作りによって自動で更新される場合もあるのでその際はこの限りではありませんが、「使われない列」となる認識は持つべきです
2.カラムの順番についての合理的な理由
特にないです。DB更新の処理であるinsertでもupdateでも列をきちんと指定すれば順番関係なく更新できます。
selectでも*とすれば一応登録された順番になりますが、とってきたい任意の順番で指定することも出来るわけですし。
あくまでドキュメントの見た目の都合ではないでしょうか。
DBにはindexなどきちんと貼ればその列に対して合理的な検索の優先度をつけることができますし、どの列がどこにあろうと関係ありません。
「現場ルール」と言い切っても良いと思います。
つまり、1も2も現場都合で如何様にも言い換えられる ということですね。
投稿2018/12/26 00:38
総合スコア80731
0
2.についてですが、データベース定義書を作っている場合、必ず、作成日と更新日のカラムを末尾にしなくてはいけないのでスプレッドシートソフトでの項番の降り直しがめんどくさいです。
私は別にupdated_at(更新日)カラムの後ろに新しく追加されたカラムを記述しても問題ないと考えますし、CREATE TABLE文を作る時にもそれで問題ないと考えるのですが、何かカラムの順番について合理的な理由はあるのでしょうか?
むしろ、Microsoft SQL Serverでは、新しい列の追加は最後にしかできません(公式)。途中に列を追加しようとすればテーブルごと作り直しとなるので、運用中のデータベースに途中の列を追加するのは、手間とリスクに見合わないでしょう。
投稿2018/12/26 00:14
総合スコア145062
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2018/12/25 20:49
退会済みユーザー
2018/12/25 21:09
2018/12/31 12:07