前回に引き続きデータベースの命名規則についてまとめる。 データベースの話の前に、いろいろ調べると命名規則に関して専門用語（？）があったので簡単に触れる。 ■snake case スネークケース 文章をアンダースコアで区切る記載方法 例）hello world → hello_world ■camel case キャメルケース 単語の先頭の文字を大文字にして区切る記載方法 例）hello world → helloWorld (camel notation キャメルノーテーション) 例）hello world → HelloWorld (upper camel アッパーキャメル) ※ちなみにキャメル＝らくだ。文字の並びがでこぼこしてらくだのコブのようだからこう呼ばれるらしい。 上記はこのあと出てくる用語。 ではデータベースの命名規則に関して、下記の記事をみつけたのでまとめてみた。 Datab
DB設計に関するsosukのブックマーク (13)
-
sosuk 2016/05/02
-
-
ネーミングルール - オラクル・Oracleをマスターするための基本と仕組み
ネーミングルールとネーム辞書 オブジェクト名、カラム名は英語だったりローマ字だったり, その混在だったりして精神衛生上に悪いことがある。 そこでいくつかのルールを設けて運用すれば、少しでも改善することができる。 注意 ここに書いてあるルールは、独自に決めたマイルールです。Oracle に関連ドキュメントがある、あるいは書籍で紹介されているなどのように、一般的に定着している、知れ渡っている類のものではありません。よって強要するような正当性もありません。 ( 何より、このドキュメントに対して他人への説得材料や根拠としてのバリューを求めてはいけません。 ) Oracle 12c R2 から識別子に使用できる文字列長が 30 バイトから 128 バイトに拡張されているので無償で使える環境にまで広がれば柔軟に対応。 スキーマオブジェクトのネーミングルール(※ マイルール) 完全に一意のオブジェクト名
-
【データベース設計】 テーブル名、カラム名の名前の付け方（命名規則） at softelメモ
データベース設計のテーブル名、カラム名の物理名について、とても個人的な自分ルールをご紹介。 テーブル名は、 小文字英数字とアンダースコアだけ使う。大文字は避ける。 一般的な英単語、ローマ字（ヘボン式）でつける。多少長くなってもいい。 頭に何かつける（t_***、m_***、c_***など）。 カラム名は、 小文字英数字とアンダースコアだけ使う。大文字は避ける。 一般的な英単語、ローマ字（ヘボン式）でつける。 頭にテーブル名を付ける。ものすごく長くなってもいい。 大文字小文字はDBMS、OS、プログラミング言語によって区別されたりされなかったりするので、無用なトラブルを避けるため。 ヘボン式で統一すれば、ツはtuなのかtsuなのか、シはsiなのかshiなのかで迷わなくなる。 テーブル名に t_***、m_***、c_*** などを付けて、テーブル、マスタ、多対多の関連を表すテーブル、ログ的な
-
-
ウノウラボ Unoh Labs: RDBで階層構造を扱うには？
yukiです。ダイエットを始めて3kg減ったと思ったら、風邪を引いて見事に1kg増量。 運動しないと駄目ですね。あと残り20kg、道のりは遠いです。 さて今回は、「RDBで階層構造を扱うには？」です。 あるサイトを構築中に階層構造をもったカテゴリ構造にすることになり、どのようにDBで扱うか悩みました。 DBはMySQLを採用していたので、この時点でぱっと頭に浮かんだ選択肢は以下のようなものでした。 XML-DBを利用する 親カテゴリレコードのプライマリIDを子カテゴリレコードに持たせる 親を含めた『絶対パス』を名称として扱い、取り出した後にパース ファイルシステムに同様のディレクトリ構造を作り、毎回パースする (1)のXMLDBはオープンソースのeXistやXindice、Yggdrasillなど様々な選択肢がありましたが、カテゴリのみの利用な割にメンテナンスコストが高すぎるので見送りま
-
-
fabFORCE.net - DBDesigner 4
General Information - What is DBDesigner 4? DBDesigner 4 is a visual database design system that integrates database design, modeling, creation and maintenance into a single, seamless environment. It combines professional features and a clear and simple user interface to offer the most efficient way to handle your databases. DBDesigner 4 compares to products like Oracle's Designer�, IBM's Rational
-
Jungle Java - ERモデリングツール
ERモデリングツール Posted in データベース (RSS) ER図が描けるデータモデリングツールは、非常に高価ですよね。 「SI Object Browser ER」は、同様の機能を持った従来製品と比べれば圧倒的に低価格で、好感が持てるのですが、それでも個人で購入するには辛い価格です。 そんな中、無償で利用可能な「DBDsigner4」というツールを見つけました。 MySQL、SQLite、Oracle、MsSQL等のデータベースに対応していて、日本語化も行われています。 なかなかいいんじゃないでしょうか。 「SI Object Browser ER」のように、物理名（半角英文）/論理名（日本語）を切り替えることができたら、言うことないんですけど、それはちょっと贅沢な注文ですよね。
-
制約の使い方、Unicode使用可否、明細テーブルの設計 (1/3)
前回は、データベース設計で誰もがぶつかる問題である「列名に日本語を使うか?」「どのデータ型を使うか?」ということをテーマに取り上げました。今回も引き続き、データベース設計で迷いやす点をいくつか取り上げ、筆者の考え方を参考にしていただこうと思います。 前回、説明したデータベースの標準規格SQL99では「制約」という機能が定義されており、OracleやSQL Serverなどの通常のRDBMSにも実装されています。 制約とはデータベースに格納されるデータに制約条件を付けるものです。例えば、NOT NULL制約が設定されている項目はNULLを許容しませんので、必ず値がセットされなければなりません。制約を設定した列に、値を指定せずにデータを格納しようとしても、RDBMSが制約違反ということでエラーを返します。 RDBMSで実装している制約には、表1のようなものがあります。
-
[ThinkIT] 第1回：ソフトウェア産業に産業革命を起こすデータモデリング (1/3)
日進月歩で技術革新するハードウェア産業や、ドッグイヤーで進化するITビジネスに比べ、ソフトウェア開発の現場はいまだに20〜30年前のやり方と大差がありません。徒弟制度での教育、開発ドキュメントの標準化の遅れ、精神主義がまかり通るプロジェクト管理、そして開発手段も相変わらず昔ながらの家内制手工業です。このような労働集約的なやり方を続けた結果、日本のソフトウェア産業の国際競争力は地をはっています。 「生産性向上」「コスト削減」「品質向上」、これらは製造業における共通課題です。日本のメーカ各社は、この目標を実現するために"カイゼン活動"や"最新設備導入"などの絶え間ない努力を行い、その結果、世界に冠する強さを持つまでにいたっています。 一方、ソフトウェア産業はどうでしょうか。派遣主体の会社には課題認識すら希薄です。また多くの企業にとってこれらの言葉は単なるスローガンであり、具体策が現場に根付いて
-
教科書的ではなく、現場にあったデータベース設計のコツ
前回はデータベース設計をする際に誰もがぶつかる問題である、「列名に日本語を使うか？」「どのデータ型を使うか？」ということをテーマに取りあげました。今回も引き続き、データベース設計をする際に迷いやすい点をいくつか取りあげてみようと思います。 今回は前回と同様、SQL Serverのサンプルデータベース「Northwind」を元にして、データベース設計で迷いやすい点について考えてみましょう。図1は「Northwind」をER図にリバースした中から、エンティティ「商品」「商品カテゴリ」をサブウィンドウで表示したものです。 図1のように商品を分類するためにカテゴリコードをつけるエンティティ構造はよくあります。しかし実際の販売管理システムにおいては、このようなフラットなカテゴリ構造は不便です。なぜかというと、一般に商品カテゴリなどは表1のように階層構造で分類する必要があるからです。 01 ハードウェ
-
日本語名の是非とデータ型採用方針
第1回はツールを使った実践的なデータモデリング手法、第2回はその基礎となるERの知識とツールの活用方法について解説しました。よくあるデータモデリングそのものの解説はこれくらいにして、今回からはデータベースのテーブル設計をテーマにします。データベース設計を行う際にみなさんが迷うようなことを1つずつ取り上げ、一緒に考察して行きたいと思います。 2進法の世界に生息しているせいか、我々エンジニアは物事を正解か不正解かに断定してしまいがちです。また、非攻撃的な生き物なので表立ってはっきり主張する機会は少ないのですが、「絶対こうじゃなければだめだ」「こんなのは信じられない」などと結構固い信念を持っている人が多いようです。 確かに数値計算の世界では、1 + 1 = 2というように正解が求められます。しかし、ふと世の中を見回してみると、実社会はむしろ正解が1つとは限らないことに気づきます。データベースの設
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2024 Hatena. All Rights Reserved.
設定を変更しました