質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.51%
MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

Oracle

Oracleは、米オラクルが取り扱うリレーショナルデータベース管理システムです。メインフレームからPCまで、多様なプラットフォームに対応しています。

SQLite

SQLiteはリレーショナルデータベース管理システムの1つで、サーバーではなくライブラリとして使用されている。

PostgreSQL

PostgreSQLはオープンソースのオブジェクトリレーショナルデータベース管理システムです。 Oracle Databaseで使われるPL/SQLを参考に実装されたビルトイン言語で、Windows、 Mac、Linux、UNIX、MSなどいくつものプラットフォームに対応しています。

SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

Q&A

解決済

6回答

17851閲覧

データベースのレコードに必ず必要になっているカラムとカラムの順番について

Touhoku

総合スコア31

MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

Oracle

Oracleは、米オラクルが取り扱うリレーショナルデータベース管理システムです。メインフレームからPCまで、多様なプラットフォームに対応しています。

SQLite

SQLiteはリレーショナルデータベース管理システムの1つで、サーバーではなくライブラリとして使用されている。

PostgreSQL

PostgreSQLはオープンソースのオブジェクトリレーショナルデータベース管理システムです。 Oracle Databaseで使われるPL/SQLを参考に実装されたビルトイン言語で、Windows、 Mac、Linux、UNIX、MSなどいくつものプラットフォームに対応しています。

SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

0グッド

0クリップ

投稿2018/12/25 20:21

編集2018/12/25 20:22

わからないことが二つあります。
0. データベースのテーブルのレコードに必ず必要になっているカラムの確認と存在する合理的な理由

  1. カラムの順番についての合理的な理由

の二つです。

 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ページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答6

0

それは質問者さんの属する組織のルールとか、DB を使うアプリなどの仕様書などでそうすることに決めているからではないですか?

データベースのテーブルそのものに、その 3 つのフィールドが存在しなければならないとか、順序はこうしなければならないとかの「合理的な理由」というのはないはずです。

投稿2018/12/25 20:41

編集2018/12/25 20:44
退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Touhoku

2018/12/25 20:49

返信ありがとうございます。 やはり「合理的な理由」はないはずですよね。自分の意見と同じ回答が来て安心感が持てました。 idはレコードの一意性を確保するため created_atはレコード作成日を知るため updated_atはレコード更新日を知るため という合理的な理由は自分なりに考えて回答が出たのですが、他にもよくいろんな案件で使う付け加えるべきカラムとかあったら知りたかったです。
退会済みユーザー

退会済みユーザー

2018/12/25 21:09

主キーを持つのは「合理的な理由」に当たると思いますが、名前は id でなくても良いし int 型でなくても良いと思います。 作成日とか更新日は、使う側の事情以上のものは無いと思うのですが。楽観的同時実行制御に使う目的で、timestamp 型のフィールドを配置すると言うような事情があるのではないでしょうか?
guest

0

1.についてですが、データベースのテーブルには必ず、以下のような3項目(レコードid,作成日,更新日)がほとんどのレコードに存在しますが、他にも何かいつも存在するカラム定義、もしくはとあるケースでは必須になってくるカラム定義はありますでしょうか?

「データベースのテーブルには必ず、以下のような3項目(レコードid,作成日,更新日)がほとんどのレコードに存在しますが」は言い過ぎですが、フレームワークの機能的な制約や設計思想として存在することは結構あります。

何をもって合理的とするかは判断が分かれるところではありますが、
例えば「テーブル定義に一定のルールを持たせることにより、フレームワークのO/Rマッパーで提供される最低限の機能を全テーブル/モデルに確保する」というのは、テーブル単位/DB単位では合理的ではなくてもアプリケーション前提としては合理的であると思います。

フィールド個別のメリットや思想としては以下のような感じでしょうか。
(メリットや思想なので絶対的に合理的な理由にはなりませんが、それなりの

例えばIDについてはサロゲートキーという考え方に基づいて設定されますので調べてみてください。

更新日や作成日については、あると色々な面で便利なことが多いので「とりあえず」設定しておくと何かと便利です。
例えば、サービスを運用していく上で必要になったりであるとか(何らかの仕様やバグでいつの間にかデータが変わっていた際の調査のとっかかりにするとか、日時でデータをソート/抽出)、データに手軽にリビジョン機能を持たせることが出来るようになったりであるとか色々なケースがあります。

もちろんこれらは事前に運用まで含めて設計出来ればベストではあるのですが、あっても困るケースはほとんどないので形式的につけておいて運用や機能拡張の幅を確保しておくという感じでしょうか。

2のフィールドの順序については、ドキュメンテーションに関するポリシーだったり決まりだったりするだけでしょうが、「設計ルールとして強制されているフィールドを末尾に配置する」というのは、ミスを防ぐ意味や閲覧性を高める上でそれなりに有効なルールに思います。

投稿2018/12/25 22:19

tanat

総合スコア18706

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Touhoku

2018/12/31 12:05

>例えばIDについてはサロゲートキーという考え方に基づいて設定されますので調べてみてください。 新しい概念を教えてくださりありがとうございます。調べてみます。
guest

0

データベース定義書を作っている場合、必ず、作成日と更新日のカラムを末尾にしなくてはいけないのでスプレッドシートソフトでの項番の降り直しがめんどくさいです。
私は別にupdated_at(更新日)カラムの後ろに新しく追加されたカラムを記述しても問題ないと考えますし、CREATE TABLE文を作る時にもそれで問題ないと考えるのですが、何かカラムの順番について合理的な理由はあるのでしょうか?

データベースという視点なら、質問についての合理的な理由などありません。

察するに、最新の定義状態をDBツールで出力して、メンテナンスされているということでしょうか。
そうであれば、先ず、CRATE TABLE文を並び替えてローカルで実行し、それから定義状態を出力すると楽になるのではないかと思います。

多分、行われているのは開発過程での作業で、本番にはメンテナンスした定義で再度作成するのではないでしょうか。
稼働後に、定義をメンテナンスするとしたら、並び替えなどすることは無いはずですから。

面倒な作業を行う為の理由付けを求めているなら、作業自体を改善する方法を考えた方が良いですね。

投稿2018/12/26 02:37

sazi

総合スコア25083

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

ベストアンサー

テーブルは大きく3種類の運用があります

  1. マスターテーブル

正規化により任意のコードから一意にレコードを選定する

  1. データテーブル

とにかくデータの塊

  1. 中間テーブル

データ間の関連性を保持する

当然それぞれ役割が違うため必要なカラムは異なります。

質問者さんの言うidとはおそらく主キーとなるレコードを特定するカラムです
これがないともし完全にデータが一致するレコードが複数存在した場合
参照・変更・削除することが困難になります。
ただマスターテーブルについては主キーがマスターデータを特定するコードになるケースがありますし
マスターに履歴を取る場合があればレコード間でコードがだぶる場合もあるのでやはり別途
主キーが必要になったりして、すべて同じ運用ができるわけではありません。

また作成日時・更新日時については、保守のためにはあった方がよいですが、必ずしも必要とは言えず
さらに言えば更新日時はカラム毎に保持する必要がある場合もあるのでこれも単純ではありません。

主キー、作成日時、カラム1データ、カラム1更新日時、カラム2データ、カラム2更新日時、・・・

その他よく利用されるものとしては以下のようなものがあります

  • 論理削除フラグ
  • 作成者、更新者
  • 参照・更新・削除権限者(グループ)

ちなみにDBにおいてカラムの順番にはあまり意味がありません
逆に言えば昔は一度カラムの位置をきめるとあとから切り替えができなかったこともあるので
きちっとしないと気持ちが悪いという人は設計段階からかなり気をつける必要がありました
いまはそのあたりも柔軟になっているのでそれほど気にしなくてよいでしょうけど
作成日や更新日はユーザーが任意に修正するものではないので往々にして後ろに持っていかれる
ことが多いように感じます、それがまさに合理的な理由でしょう

そもそもテーブルの設計をそうそう変更することもないので、後ろにあって苦労するということは
ありません。もし気になるなら、まず設計自体を最初からちゃんとすることを心がけて下さい

投稿2018/12/26 01:02

編集2018/12/26 01:03
yambejp

総合スコア114505

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Touhoku

2018/12/31 12:10

>論理削除フラグ >作成者、更新者 >参照・更新・削除権限者(グループ) なるほど。確かに他の案件で見たことあります。思い出しました。 論理削除フラグはSELECT文に毎回フラグの検索条件をつけなくてはいけないので面倒で、論理削除済みテーブルでも用意してそちらに移動してくれないかな?とか思ったりしていました。 今回、いろいろな概念を教えてくれたこの返答をベストアンサーにさせてください。皆さん返信ありがとうございました。
guest

0

1.データベースのテーブルのレコードに必ず必要になっているカラムの確認と存在する合理的な理由

ないです。要件・仕様・設計次第で必要なカラムは変化します。

idや更新日時、登録日時すら必要がない場合もあります。

OracleなどではROWIDといって自動で入る擬似列があり、そちらをIDの代用として使うこともあります(真のキーとも呼ばれているようです)

更新日時や登録日時はシステム側の都合で入れるものなので、登録や更新が発生しないもの、トレーサビリティが必要でないものには入れる必要はありません。

※フレームワークや作りによって自動で更新される場合もあるのでその際はこの限りではありませんが、「使われない列」となる認識は持つべきです

2.カラムの順番についての合理的な理由

特にないです。DB更新の処理であるinsertでもupdateでも列をきちんと指定すれば順番関係なく更新できます。
selectでも*とすれば一応登録された順番になりますが、とってきたい任意の順番で指定することも出来るわけですし。
あくまでドキュメントの見た目の都合ではないでしょうか。
DBにはindexなどきちんと貼ればその列に対して合理的な検索の優先度をつけることができますし、どの列がどこにあろうと関係ありません。
「現場ルール」と言い切っても良いと思います。

つまり、1も2も現場都合で如何様にも言い換えられる ということですね。

投稿2018/12/26 00:38

m.ts10806

総合スコア80731

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Touhoku

2018/12/31 12:03

>1も2も現場都合で如何様にも言い換えられる やはりそうだったのですか。返信ありがとうございます。疑問が晴れました。とても分かりやすかったです。
guest

0

2.についてですが、データベース定義書を作っている場合、必ず、作成日と更新日のカラムを末尾にしなくてはいけないのでスプレッドシートソフトでの項番の降り直しがめんどくさいです。

私は別にupdated_at(更新日)カラムの後ろに新しく追加されたカラムを記述しても問題ないと考えますし、CREATE TABLE文を作る時にもそれで問題ないと考えるのですが、何かカラムの順番について合理的な理由はあるのでしょうか?

むしろ、Microsoft SQL Serverでは、新しい列の追加は最後にしかできません(公式)。途中に列を追加しようとすればテーブルごと作り直しとなるので、運用中のデータベースに途中の列を追加するのは、手間とリスクに見合わないでしょう。

投稿2018/12/26 00:14

maisumakun

総合スコア145062

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Touhoku

2018/12/31 12:04

>むしろ、Microsoft SQL Serverでは、新しい列の追加は最後にしかできません そうだったのですね。MS製品には疎いのでこれは新しい観点です。返信ありがとうございます。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.51%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問