特に、リレーショナルデータベース管理システムでは、作成時に列のデータ型（おそらくオブジェクトの属性）を知る必要があるのはなぜですか？なぜデータ型が気になるのですか？
データ型は、1つのデータポイントをさまざまな方法で実装できるため、最適化のように感じられます。データポイントにセマンティックな役割と制約を割り当て、エンジンがユーザーに最も効果的なデータ型を内部的に調べて最適化するようにする方がよいでしょうか？
私はこれが重い持ち上げがどこにあるのか、なぜ仕事をするよりもユーザーに聞きやすいのはなぜだろうと思っています。
あなたはどう思いますか？どこに向かうの？これは現実的な期待ですか？または私は間違った前提を持っていますか？
あなたが正しいです：データ型を列に割り当てることは実装の詳細であり、データベースエンジンの背後にある集合理論や計算とは関係ありません。理論的なモデルとして、データベースは「タイプレス」であり、私たちがそれに投げたものを格納することができなければなりません。
しかし、私たちは実際のコンピュータで実際の制約を使ってデータベースを実装する必要があります。パフォーマンスの観点から、コンピュータにデータを最適に保存する方法を動的に把握させることは実用的ではありません。
たとえば、数百万の整数を格納するテーブルがあるとします。コンピュータは、各データを整数値として格納すべきであることを正しく理解することができました。しかし、ある日突然そのテーブルに文字列を格納しようとすると、すべてのデータをより一般的な文字列形式に変換するまで、データベースエンジンはすべてを停止する必要がありますか？
残念ながら、データ型を指定する必要はありません。
データベースはすべて物理ストレージに関するもので、データ型はこれを定義します。
この型は、列の値に望ましい制約を表します。
答えは、格納スペースと固定サイズの行です。
固定長の行は、どのレコード番号とフィールドが必要なのかを知っていれば、正しいバイトに直接アクセスできるので、可変長の行よりも検索がずっと高速です。
編集：データベーステーブルで適切なインデックスを使用すると、以前は固定サイズの行の重要性はそれほど重要ではないと言われています。
それは答えのほんの一部であり、それの最も重要な部分から遠いです。 –
SQLiteは気にしません。それは、パフォーマンスのために不可欠だったとき、S
その他RDBMS「早期に設計されたの使用の原則」が。
オラクルは、例えば、NULLと空の文字列を区別しない、とcentesimal桁のセットとしてそのNUMBER年代を保持します。
今日はほとんど意味がありませんが、オラクルが開発されているときは、これは非常に巧妙な解決策でした。
私が開発したデータベースの中には、インデックス付きでない値が使用され、VARCHAR2として格納され、いくつかの条件によって適切なデータ型に動的にキャストされました。
これは、コレクションを使用してデータベースへの1回の呼び出しで、キーと値のペアを一括読み込みするために使用されていました。
ダイナミックSQLステートメントは、データを解析し、キー名に基づいて適切なテーブルに入れるために使用されました。
すべての値を一時的なVARCHAR2カラムにロードしてから、NUMBERとに変換するように変換します。
右のRDBMSアーキテクチャはO-L-Dです。 –
データベースのデータ型の履歴はわかりませんが、私にはフィールドのデータ型を知ることは意味があります。
いつ完全にvarcharのいくつかのフィールドの合計を行いたいですか？ フィールドが整数であることが分かっている場合は、合計、平均、最大などを行うのが理にかなっています。
また、varcharには独自の制限もあります。 nvarcharはvarcharよりも自由ですが、コストがかかります。 – Joseph
明示的なデータ型は効率とストレージにとって巨大です。彼らが暗黙的であれば、彼らは「考え出され」なければならないので、スピードコストが発生します。インデックスも実装するのは難しいでしょう。
私は、陽性ではありませんが、明示的なタイプを持つことで平均的にも記憶スペースが少なくなると疑いがあります。特に数値の場合、バイナリintと数字の文字列の比較はありません。
です。数値が1桁または2桁の場合、文字列はINTEGERよりも短くなります。しかし、一般的に、はい：バイナリタイプは、対応する文字列よりもメモリとディスクの方がコンパクトなことがよくあります。特に、日付はバイナリ表記では短くなります。 –
フィルタリング（WHERE句）またはソート（ORDER BY）については、データ型に注意してください。たとえば、値が文字列の場合は「200」は「3」よりも小さく、整数の場合は逆になります。
あなたはデータをソートしたりフィルタリングしたりする必要があります（ "200"> "3"？）か、sum（）や（avg（））のようなレポートで集計関数を使用する必要があります。テキストデータ型で良いです:)
Hm ...あなたの質問は紛らわしいものです。
私が正しく理解しているのは、なぜテーブル列のデータ型を指定するのか、なぜ「エンジン」がユーザーに必要なものを自動的に決定するのかということです。
データ型は制約として機能し、データの整合性を保護します。 int型のカラムには文字は入っていません。これは良いことです。データ型は自動的に決定されません。データベースの作成時に指定します。ほとんどの場合、SQLを使用します。
すべてのデータベースがこの方法で動作するわけではありません。以前はSQLiteが言及されていましたが、もっと古いデータベースセットでも、これは多値データベースとなります。
UniVerse（現在はIBMの財産）を検討してください。データの検証は行わず、データのタイプを指定する必要もありません。検索はまだ（比較的）高速ですが、（データを動的に格納する方法のために）スペースが少なくなります。
メタデータ（辞書項目）を使用してデータがどのように表示されるかは説明できますが、これはデータの制限方法の制限です。
あなたは5ヶ月で億行をプッシュしているときなどは、このようなアンチパターンはありません後（我々のシステムでは）、ライブ
をすべてのバイトカウントを行くUniVerse
上のWikipediaの記事を参照してください。データベース設計における「時期尚早の最適化」
ディスク容量は安いですが、メモリ内のデータを使用します。
一部のデータ項目が整数であることがわかっていて、意図的にDBMSにこれを強制させないことを選択した場合、データの完全性システム動作の一貫性（値 '01'が値 '1'と等しくなることを保証する）のように、列に値「A」を入力することはできません。これはString型から得られる動作ではありません）...
タイプは、あなたのためにあらゆる種類のものを処理します。
私がデータベース理論で読んできた本は、SQL標準がドメインという概念を定義していることを示しています。例えば、高さと幅は2つの異なる領域であってもよい。どちらも数値（10,2）として格納されている可能性がありますが、高さと幅の列はキャスティングなしで比較できませんでした。これにより、実装に関係しない "タイプ"制約が可能になります。
私はこのアイデアは一般的に好きですが、実装されたことは一度も見たことがないので、それを使うのはどういうことか分かりません。私は、概念的なドメインが全く異なっているときに、実装が同じになる値を使用する際のエラーの可能性を減らすことができます。また、例えば、人のcmやインチの比較を防ぐのに役立つかもしれません。
SQL標準は、ドメインを限定しています。標準は広く普遍的ではないにしても、この詳細では広く無視されている。確かに、SQL標準が提供するものは、関係理論家が理解するものと一致しません。 –
RDBMは一般的に列タイプの定義を必要とするため、検索を高速に実行できます。巨大なデータセットの各行の5番目の列を取得したい場合、列を定義することは大きな最適化です。
5列目を取得するために各行をスキャンする代わりに（列幅が固定幅でない場合）、RDBMはsizeOf（column1-4（bytes））+ sizeOf（column5 （バイト））。これが10,000,000行のテーブルにどれくらい速くなるか想像してみてください。
また、各列の種類を指定したくない場合は、私が認識している2つのオプションがあります。各列をvarchar（255）として指定し、呼び出し元プログラム内で何を処理するかを決定します。または、Redisなどのキーと値のペアを使用する別のデータベースシステムを使用することもできます。
制約はおそらくここで言及されている最も重要なものです。データの正確性を保証するためのデータ型が存在するため、正しく操作することができます。日付を保存するには2つの方法があります。ある型の日付または文字列 "1893年1月4日"。しかし、文字列は "4/1 1893"、 "1/4 1893"などとすることもできます。データ型はそれを制約し、日付の正規形を定義します。
さらに、データ型にはチェックができるという利点があります。文字列 "0th of February 1975"は文字列として受け入れられますが、日付としてはなりません。 1983年2月30日はどうですか？ MySQLのような貧弱なデータベースは、デフォルトでこれらのチェックを行いません（ただし、MySQLを設定することはできますが、そうする必要があります）。
データ型はデータの一貫性を保証します。これは、あなたのデータを狂気から守るために、最も重要な概念の1つです。
それはよく簡潔に入れられました。これは、データ整合性制約がデータベースに属していることを意味します。これはあまり議論の余地がありませんが、一部の人々はデータベースを厳密にデータのダンプとみなし、すべてのビジネスルールがアプリケーション内にあることを望んでいると思います。したがって、 '所望の制約'。 – JosephStyons
。実装者まで！ –
私は実際にこの答えが嫌いです。私は今日のデータベースシステムの実装タイプが、与えられた列の可能な値を制約するのに十分な特異性を提供しているとは感じていません。このため、実装の詳細とデータの意味的役割とを区別しました。たぶん私は十分にはっきりしていない、私の悪い。 –