ここでいうデータベース設計とは、
特定の業務システムにおける
テーブルレイアウトを設計し、決める作業であるとします。
業務システムにおいては、
このデータベース設計（テーブル設計）は仕様そのものを定義する作業にも
近いと思いますし、この設計は開発工程やその後の運用における品質を
絶対的に左右するものだと思っています。
逆にこの設計があまりにも実現すべき仕様と比較し不整合なため、
その後の開発工程がデスマーチに陥ることも少なくないのではないでしょうか？
にも関わらず、正規化程度も理解できないような担当者が
この設計を行っていたり、業務システムの受託開発において、
「テーブルレイアウトを決める」という作業が、あまりにも軽視されているような
気がしています。
みなさんの現場ではどうでしょうか？
ご意見などお聞かせください。
1970年1月1日0時0分0秒からの経過秒数をDBに整数型で入れてるってこと？
…それはナイスな方法だな。今度使わせてもらうわ。
というか死んだ
プログラム上でだっていちいち変換して使わなきゃならんのだし
そういう型がないRDBMSなら仕方ないと思うけど。
変換するコストもいらないし。
入力は？
日付や時刻関連でGROUP BYするときにちょっと殺意が沸くくらいだな。
全然普通
要求性能にもよるが、10年前のハイエンドクラスだときついだろうね
0.25人月で60万円でおｋ
俺のとこなんて1人月120万だよ基本orz
ttp://twitter.com/ozawa_yuuki/status/6549767047872513 国家資格（笑）の情報処理試験受けたことあんのかと
あんなもん実務に役立つのはどのポジションだろうが2割程度だろ
「プラズマテレビがガス放電で発光してます」とか知ってる必要あんの？
IPAは今年度になってようやく業界のゼネコン型に言及するレベル
お勉強しか出来ない無能集団の天下り先
国家自体が無能で仕事遅いしなｗ
ロジックとデータ（論理・物理）見てテストして
壁にぶち当たってマニュアルやら仕様書見て
ソースとデータ（論理・物理）見てｒｙ・・・・ループ
この作業以外で技術力を上げる方法なんか存在しない
糞ﾜﾛﾀお前の情試の例はよりによってITパス/FEの午前かよｗ
高度のスペシャリスト系は良く出来てる
所詮知識なので合格即実務で出来る、ではないが
「この程度も知らずに実務やってないよね？」感はある
高度がよく出来てる？
アホか？回答速報当日出ないような奇問も混じってるわけだが？
お前はずっとFE午前レベルの「プラズマテレビの〜」だけやってろｗ
お前みたいに高度もとれない程度の知識レベルの奴が設計してるシステムとか・・・
関わってる連中が可愛そうだわ。まさにスレタイにピッタリな人間ｗｗｗ
難易度低い時に受けてたまたま取れたヤツが偉そうにしてるの見ると痛々しくなるよな。
基本はわかってるが応用効かないし、製品個別の仕様部分を考慮できなかったりロクなヤツがいない。
逆に末端がどんどん依存してくれるから後で変更するのがた〜いへん。
わかってるとこだとDB設計にコストかけてくれる。
わかってないとこだと作る側の営業と使う側の購買が交渉にコストかけてくれる。
後者、会社関係単位で迷惑。
詳細テーブル全てに予めtempカラム群持たせるのって、
個人的にはかなりの糞だと思うんだが・・・
ところで激安中古CAD専門店っていいの見つけた。
かなり安いし使える
何百万レコード級のテーブルを
使ったことはある？
ALTER TABLEだけで何十分とか
当たり前にかかったりするぞ。
それを思えば、ハナからバカにした
ものでもない。
レコード数が多いからこそ、カラム数を減らすべきだってことが分からないのか？
あいつらなんでもかんでも一行づつ処理しようとする。
処理時間=一行の処理時間(一定)×行数
はRDBじゃ通用しないんだよ
「ここでSQLのSUM関数で合計を取得します」
「それ信用できるの？ちゃんと一つずつ足さないとダメだよ」
２１世紀でこれかと驚いた
ケースバイケースだと言ってるんだよ。
絶対どっちか、というものではない。
予備カラムがあっても、理由が充分なら、
それでよいではないか。
検索パフォーマンスが必要無いならxml型にするって手もあるけど
予備項目を活用する分には保守の範囲内で出来るから
予備を多めに作っとくっていうのがあったな
クソだと言われてる設計でも事情でそうなってるのも結構あるよね
画面から予備カラムにセットする値にも制限掛からないから、変な値入ってバグってみたり。
予備カラムをあらかじめ作る必要性はうすい
COBOLだから予備カラムつくるんじゃなくて、それが動いているプラットフォームが
固定長バッファのシーケンシャル入出力を基本としてたから必要なだけ
あんな天下り先確保のための試験を
ボッタクリ価格で受けるとか、
怒りが湧いてくる。
とはいえ午後1は酷い問題混じってることあるから、選択運の要素が強いけど。
安いので許せや
酷い問題のってどれですか
は取れなかった奴の言い訳じゃね (w
www.2ch.net
toro.2ch.net/db/
toro.2ch.net/test/read.cgi/db/1228061247/
せっかく合意のとれた業務フローとテーブル設計を
180度ひっくり返しに来る奴（客・身内問わず）がいるから
それが最初からわかってるから軽視される
ちょうど私はその時新しいパソコンがほしいと思っていて本当に買おうかと悩みました。
というのも２０１１年製でCPUがCorei5、メモリも４ＧＢあるしHDDが１ＴＢもあってお値段がなんと３８０００円でした。
まだ発売日からあまり期間も経っていないしこのスペックでこの値段ならかなりお買い得かなと思ったのですが、問題は少スペース型というか拡張性がないタイプのものだったんです。
それにグラフィックボードもついておらず後々の事を考えるとやめといたほうがいいかなという結論に達しました。
結局ネットでBTOのパソコンを後で注文しました。
いやぁしかしまさか周りにあるパソコンの中で一番スペックが高いのに一番安い値段になってるとは思いませんでした。
ttp://toro.2ch.net/test/read.cgi/hp/1382021349/ ttp://toro.2ch.net/test/read.cgi/hp/1352858999/ どんなプログラミング言語を学習すればいいですか？
競馬を通してプログラミングを勉強すれば楽しいと思うし、
仕事にも役立つとなれば一石二鳥。
データーソースは外部の物を利用。
日本小学校
１年 |２年
1組 ２組 | 1組 ２組
座席番号１安藤 伊藤|五十嵐 飯田
座席番号２臼井 榎本|上田 岡田
座席番号３０（全クラス３０で統一）
↑をデータベースに格納しようとすると
こういう風な感じになると思いますが
日本小学校 一年 1組 座席番号1 安藤
日本小学校 一年 1組 座席番号2 山田
日本小学校 ２年 1組 座席番号1 伊藤
視覚的に編集するには前者の方がやりやすいですよね
こういう前者のデータ構造は何か名称があったりしますでしょうか
また前者のテーブルの横にアメリカ小学校を追加する場合もあります
こういうデータを管理するために何かいいツールとかないでしょうか？
データベースに格納できるよう変換してくれたり
１年 |２年
1組 ２組 | 1組 ２組
日 座席番号１安藤 伊藤|五十嵐 飯田
本 座席番号２臼井 榎本|上田 岡田
小
ア 座席番号１ボブ トム
メ 座席番号２マリー
リ
カ
小
こんな風にしたり
そもそもそれはデータ構造と呼べる代物かが疑問なんだが
表現方法としては「マトリクス表」とか呼べばいいんじゃね？
ツール？excel使えばいいじゃん
excel VBAでcsvを出力するマクロを作れば終いだ
どうもです！
◎ +ニュース板
・ 2NN
・ 2chTimes
◎ +ニュース板新着
・ 2NN新着
・ Headline BBY
・ unker Headline
◎ +ニュース板他
・ Desktop2ch
・ 記者別一覧
◎ 全板
・ 全板縦断勢いランキング
・ スレッドランキング総合ランキング
・ ログ速
◎ 全板実況込み
・ 2勢
・ READ2CH
・ i-ikioi
※ 要サイト名検索
同県蕨市南町、東大大学院博士課程の内藤慶一容疑者（２６）を逮捕した。
川口署によると、内藤容疑者は「研究が忙しく、ストレスがたまっていた。少女に興味があった」と供述している。
逮捕容疑は１月４日午後５時半ごろ、埼玉県川口市並木２丁目の書店１階の階段近くで、
当時９歳で小学４年だった女児の下半身を触った疑い。
書店の防犯カメラ画像を解析するなどして内藤容疑者が浮上した。
３月上旬に近くのスーパーで別の女児が下半身を触られる被害があり、関連を調べる。
ttp://www.47news.jp/CN/201407/CN2014072001001585.html 役に立たないんだよ。
まじで。
オプティマイザがいい仕事するんやで
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。
インターフェイスって何？
> 噂の日教組保育士がまた報復やったってさ
>
> 749 名前：名無しピーポ君 ：2015/11/24(火) 12:41:16.38
> あーーーー在日居住地にある能満幼稚園の
システム間インターフェイスだとしても、ユーザーインターフェイスだとしても間違っているか？
Googleの検索システムがKVSの御時世に何言ってっだこいつ？
8年前の書き込みに何言ってっだこいつ？
自演なのかも知れんがクッソワロタ
データベース設計を「テーブルレイアウトを決める」という作業と捉えてる時点でDB設計を軽視してるんだよね
テーブル設計はDB設計の中でも末端作業だから、そういう認識から変えたほうがいい気がする
経験上、DB設計出来ますってやつのうち概念設計や論理設計がまともにできるやつは20人に1人いればいいほう
論理設計が出来るとは思ってないが
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことを
末端作業と言って軽視すのは
どうかと思うよ
それも最後のほうにやる作業だって意味
ある業務に関わるデータをどういうデータ構造で管理するのが適切かを考えようとしてる時に
「Excelのフォーマットを決める」ような作業が、RDBなら「テーブルレイアウトを決める」という作業
「どういうExcelフォーマットにしようか」ってのと同じ観点から始めて
テーブル定義書と申し訳程度のER図を書くことがDB設計だと思ってる人がすごく多い
DB設計はテーブルレイアウトを決める作業じゃなくて、DB設計の結果としてテーブルレイアウトが決まる
クラス図とクラス定義書を書くのが設計だと思ってる人はほとんどいないけど
DB設計においてはそのレベルの人がたくさんいるよね
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ
それだけの話
それらを必要に応じて
敢えて崩すのはアリだけど
正規化をやらないとかはありえない
それって結局、DB設計をテーブルレイアウトを決める作業と捉えてて
テーブルレイアウトを決めるのにはそれらが最も大切だって言ってるんじゃねーの？
例えば正規化ってOOにおけるSRPやOCPみたいな設計原則に相当するものだよ
SRPに従ってクラスを分けることがシステムやプログラム全体の設計の中で最も大切だったりする？
クラス定義においてならまだ理解できるけどさ
それと同じで正規化の知識は必須だし、業務アプリなら当然その設計原則に従ったモデルを作るんだけど
DB設計において正規化することが最も大切なわけではないよ
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するといったことが
最も大切だよ
それより大切なことって何かな？
>何故データベース設計は軽視されるのか？
理由を考えてみたが、教育不足と経験不足が大きな原因だと思う
まず一般的なプログラムの設計に比べてDB設計はその機会自体が圧倒的に少ない
それはプログラムに比べてDBは数も少なくライフライクルも長いし、プログラム設計に比べればDB設計は一人で担当できる規模が大きいから
機会自体が少ないから、業務アプリに関わるエンジニアの中で繰り返し何度もDB設計の経験が積めるような人も当然少ないし
その中でも優れたDB設計者となるともっと少ない
だから一部のDB設計に特化した会社や部門を除くと、かなり大手でもDB設計に関してまともに後進の教育や育成ができるような人はすごく稀
そうでない人たちに教育・育成されたエンジニアが大多数を占めるからDB設計が軽視されることが自然と多くなる
DB設計能力の低いと、どうしてもプログラムの処理に重きを置きがちで
プログラムからデータをどう使いたいかという観点でDBを設計しちゃう人が多い(=DB設計の軽視)
そういうやり方を見てきた人たちはそれが当たり前だと考えるからDB設計軽視が再生産される
個人レベルでは優れた教育を受けたり、数多くの経験を積むことで負の連鎖からは抜け出せそう
会社レベルではDB設計の機会の少なさと重要性を認識して、優れた育成者を多く育てる努力が必須かな
DB設計において最も重要なことは
ビジネスドメインと要求を深く理解して適切なデータモデルを作ること
ビジネスドメインと要求を深く理解するというのは
そもそもデータベース設計レベルの話かい？
そうだよ
ちゃんとしたデータベース設計には必須だよ
対象のドメインと要求を深く理解しないと適切なデータモデルは作れないから
だからプログラムの実装に近い人がDB設計するよりも
要求分析をする人で技術力もある人がDB設計をしたほうがまともな設計ができることが多いよ
後者の場合は組織や責任者がDB設計にとって何が重要か理解しててDB設計を軽視してないっていう理由も大きいけどね。
ふむ
要求分析をする人で技術力もある人が
ビジネスドメインと要求を深く理解して適切なデータモデルを作れば
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義するのは
やらなくて良いと仰りたいなかな？
大局的には「計算機で効率的に処理可能な形式で対象を表現したモデル」――「対象領域の計算機向けモデル」（数理モデルとか、あっちの意味でのモデル）の構築こそが根本であるので、
それを重要視する、ということ？
でも個人的には正規化などのtuple（型）の設計しながらフィードバックしていって上記の概念を理解・把握・構築している感じがある
具象から始まり抽象化する、というか、つまり何なのか、を追求していくとそこに至るというか
なので個人的には 兼 ww
データベースに長けた人からみるとまた違うのかな？
ビジネスドメインと要求を深く理解して適切なデータモデルを作る
という作業の中に
テーブルを正規化したり
適切なデータ型を決定したり
制約を定義する
という作業が内包されてるなら
そもそも比較することが間違い
ほぼ機械的に決定して薦めれるからなぁ
本質的に不可分なのだという主張なら、それはそれというか、方向性としてはわかる。
もっとも、そうなるとその線引きは難しいだろうけど。
機械的にやれるからと言って軽視するのが
そもそも間違い
DB設計の一部である概念設計は要件定義の一部
という考え方なので不可分といえば不可分
フェーズの呼び方は会社によって違うだろうけど
要件定義時に概念設計,
基本設計時に論理設計,
詳細設計時に物理設計が基本
DB設計の質を一番大きく左右するのが概念設計
エンティティの漏れやリレーションの間違いがあると
制約の定義漏れやデータ型の選択ミスとは比べられないレベルの悪影響が出る
(正規化の多くは概念設計で行われる)
もっと狭義のDB設計フェーズという考え方があるのかもしれないけど
そういう考え方自体がデータベース設計軽視につながっている可能性があるのかも
その考え方を徹底すると、DB設計はなくなりそう。ｗ
機械的にやれるということと、軽視するということには関連性がない
君はいったい何と戦ってるんだ？
概念設計、論理設計、物理設計のどの段階で正規化するの？
普通は初めから正規化したようなまとまりで考える。
概念を正しく論理モデルにする作業が正規化だろ
の言うとおり、どこかで正規化の工程があるというよりは
最初からほぼ正規化されたモデルで考えて
モデルを改善するたびに正規化違反をチェックしながら都度対応する
なので概念設計が終わったらその段階まででの正規化も終わってる
論理設計時にはサロゲートキーや削除フラグみたいなのが追加されて
正規化が崩れる場合があるからその場合も都度判断して対応する
物理設計では正規化に関わるようなところは基本的にいじらない
DB概念設計のインプットになるようなドメインモデリングをする時は
概念間の関係とわかりやすさを重視するので正規化されてるかどうかは気にしない
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
DX2Z9GYZ7S
