DB設計を語るスレ 10 [無断転載禁止]©2ch.net

1NAME IS NULL2017/05/22(月) 16:38:31.52ID:???
語れ

前スレ
DB設計を語るスレ 9
http://echo.2ch.net/test/read.cgi/db/1444733172/

196NAME IS NULL2018/01/25(木) 16:14:20.92ID:???
たとえばカラム一覧が
id,name,address,telephone,comment,date

だとする。そして「携帯電話」を追加したい。
こういった要件の場合、
id,name,address,tel,mobilephone,comment,date

ってしたくならないか?
id,name,address,telephone,comment,date,mobilephone

だとなんか納まりが悪いじゃん

197NAME IS NULL2018/01/25(木) 16:16:11.62ID:???
修正。2番めに書いたのが無駄に削ってしまった。
id,name,address,telephone,mobilephone,comment,date

198NAME IS NULL2018/01/25(木) 16:22:13.38ID:???
それは趣味の話であって、設計の話ではない

199NAME IS NULL2018/01/25(木) 17:12:08.82ID:???
>>196
言いたいことはわかるけど、
本来リレーショナルデータベースにはそうした順序性が存在しない

200NAME IS NULL2018/01/25(木) 17:14:48.52ID:???
>>198-199
いやだから、気になりませんか?って話です。
本質とかルールがどうこうではなく、心情的な面で。

201NAME IS NULL2018/01/25(木) 17:22:02.78ID:???
気になるもクソもRDBってのは「集合」を扱うもんなの
そして集合には順序なんて概念はないの

202NAME IS NULL2018/01/25(木) 17:23:25.83ID:???
>>199
もちろん、ユーザに見せるときにはSQLではなくプログラミング言語で調整しているよ

203NAME IS NULL2018/01/25(木) 17:25:46.44ID:???
じゃ、テーブル設計書作ってるときとかphpMyAdminを利用してるときとかなんでも良いです。
順序がないけど順序を視覚化しているツールを使っている時に、
カラム名やデータ型が異なる順番で並んでると気になりませんか?

単に気持ちの問題ならどうでもよくても、仕様書にした場合、
順序がバラバラだとミスや勘違いの原因になりやすいのではないでしょうか?

204NAME IS NULL2018/01/25(木) 17:30:24.66ID:???
>>203
気にはなるけどリレーショナルデータベースとはそうしたもんだ

仕様とはまったく別の話
ある順序通りに列を並べたいというのが仕様にあればアプリ側で対応すべき話であって
その順序をDBに持ち込むことがおかしい

205NAME IS NULL2018/01/25(木) 17:32:15.39ID:???
>>204
つまり、
>>196の要件で「携帯電話」を追加したい場合、
id,name,address,telephone,comment,date,mobilephone

で良いということですか?
これは順序も何も考えて無くて、単に末尾に追加しているだけです。

206NAME IS NULL2018/01/25(木) 17:38:50.08ID:???
>>205
何度も言っているように、DBはそれで良い
というか、そこで順序にこだわることがおかしい
ユーザ側に見せる時には、プログラミング言語(JavaやC#やPHPでもなんでも)で調整すべき

207NAME IS NULL2018/01/25(木) 17:39:52.94ID:???
205はリレーショナルモデルの勉強をした方が良いのでは

208NAME IS NULL2018/01/25(木) 18:03:00.90ID:???
エクセルに切り替えれば解決

209NAME IS NULL2018/01/25(木) 18:05:52.91ID:???
順序にこだわるのは、>>203にも書いたとおり、
仕様書なり設計書なりを見た人物(自分含む)が
誤認しないか?正しく伝わるか?と思ったからです。

過去にカラム追加が必要だと思ってたら、既にあったということがありました。
正規化しても1テーブルに100近いカラムが並ぶこともあるわけで、
とかく順序を意識して行いと、そういった不具合や誤認が生まれます。

リレーショナルデータベースとしては何が正しいか・正しくないかではなく、
扱うのは人間です。人間にわかりやすいのが一番だと思っています。
その上で出た疑問です。

210NAME IS NULL2018/01/25(木) 18:08:44.34ID:???
たとえばMySQL「AFTER」というコードが有るのも、「指定位置に追加したい」
という需要があったからこそ用意されたのではないでしょうか?
そうでなければ末尾でも良いわけです。

211NAME IS NULL2018/01/25(木) 18:12:05.73ID:???
何のためにほとんどのアプリでUIが別途あると思っとる
そういう整形はフロントエンドの役目

212NAME IS NULL2018/01/25(木) 18:13:18.10ID:???
>>209
まさかと思うけど
リレーショナルデータベースをphpMyAdminで直接編集しようとしている?
(そんなはずはない、と思いたい)

>カラム追加が必要だと思ってたら、既にあったということがありました
というのは、単にモデリングの欠陥を言っているだけで、

>正規化しても1テーブルに100近いカラムが並ぶこともあるわけで、
これもよくあるアンチパターンで、1テーブル100カラムというのはほとんどが設計ミス

>人間にわかりやすいのが一番だと思っています
とか言い訳しているけど、単なる知識不足にすぎないのでは

213NAME IS NULL2018/01/25(木) 18:19:21.67ID:???
teratailを見ると以下のように回答している人がいました。

「カラム位置のパフォーマンスへの影響ですが、一般的にRDBMSは可変長カラムを後ろに持っていった方が性能は良いです。可変長カラムより後ろのカラムに対しては、実際のデータ長を見て毎回オフセットを計算する必要があるためです。」

これを読み解くと、カラム位置って大事じゃないんですかね?
この回答者が間違っていると言われればそれまでですが。

214NAME IS NULL2018/01/25(木) 18:26:41.60ID:???
>>213 DBの実装に依存する
これまでの君の主張は見た目の順序のことだから
的外れの突っ込みだぞ

215NAME IS NULL2018/01/25(木) 18:41:36.73ID:???
どうしてもやりたきゃ
別テーブル作ってそこにコピーしてリネームすれば

216NAME IS NULL2018/01/25(木) 18:54:38.23ID:???
それこそ無駄じゃないですか?

MySQLに順序変更に関するコマンドがある以上、
私の質問ってそんな的外れじゃないと思うんですけどね
「DBに順序という概念はない」っていう意味はわかりますけども。

217NAME IS NULL2018/01/25(木) 19:13:05.84ID:???
DBに依存する処理だけど、やりたければやれば良いのだと思うよ
>>216 の動機はやはり的はずれだと思うけど
みんなが言っているようにアプリで対応するのじゃ駄目なの?

218NAME IS NULL2018/01/25(木) 19:36:37.81ID:???
まあしかし、心情的には理解できなくもない
最終更新日や削除フラグ(笑)の後ろに項目あると、ああ、あとから追加したんだなと切ない気持になる

DBMS的にはカラムは後ろにしか追加できない場合がほとんどだろうけど
GUI系の管理ツールだとテーブル作り直して間に追加したかのごとくしてくれる物もあるぞ

219NAME IS NULL2018/01/25(木) 19:37:01.16ID:Kd6btbkD
>>216
また馬鹿が調子こいてでまかせ言ってたみたいだなw
迷惑かけてすまんのうw

×:「DBに順序という概念はない」
○:「関係モデルに順序という概念はない」

RDBMSの標準SQLでは定義された列の順番が存在する

よってお前の質問は全く的外れではないし
後から途中に列を挿入するという仕様変更も間違いではない

220NAME IS NULL2018/01/25(木) 19:40:17.60ID:???
>>219
「DBに順序という概念はない」は216だけが言ってるんじゃないかな
そして標準SQLでは, 途中に列を挿入する処理は存在していないんじゃない?

221NAME IS NULL2018/01/25(木) 19:52:49.07ID:???
>>220
少なくとも質問者である私は「DBに順序という概念はない」って言っていません。
回答者がそうおっしゃるから、自身の知識を改めただけです。

222NAME IS NULL2018/01/25(木) 19:55:46.45ID:???
返信が前後しますが、>>218さんみたいな意見があれば「やっぱり切なくなりますよね」
って思うだけです。自分も切なくなるから質問したわけですし。
かといってテーブル作り直すレベルまでもとめていません。
何度も書きますが、MySQLだとカラム同士の間に挿入できるわけですから。

ググっても「こうするべき」的な情報もないので質問したわけですが、
よくわからなくなってきました。もう半端な知識で適当に行きます。
みなさん、色々ありがとうございました。

223NAME IS NULL2018/01/25(木) 19:57:33.96ID:???
>>221
>>216でそう言っているよね? 正解は>>219の通りだけど

>>199>>201>>204 も, みんな同じことを言っていると思う

224NAME IS NULL2018/01/26(金) 02:01:50.61ID:???
>>222
MySQLでしか通用しない小手先をもって「こうするべき」なんて言うやつおらんて

225NAME IS NULL2018/01/26(金) 02:15:25.24ID:???
カラム数が100近くになるというのは、そこからしてメンテ困難な状態でしょう
順序に拘る、気にするよりも設計に問題がなかったか見直した方が良いように思う

226NAME IS NULL2018/01/26(金) 02:18:38.09ID:???
>>222
カラムの順番が重要視される会社で開発しているとしよう
同僚のコードはテストを通っていたが、マージはリジェクトされてしまった
あなたが先にマージしたコードのせいで、カラムの位置が不適切になったためだ
同僚はコードを修正する事より、規約を考えたあなたを殴る事を優先するだろう

227NAME IS NULL2018/01/26(金) 02:35:15.34ID:???
>>218
心情的にはこれに同意だな

実務的な話をするなら、工程による。設計中なら、気の済むようにしたらいいけど、運用後の仕様変更だと、間に挟む為だけにテーブル作り直すとは客に説明できん..

MySQLは使ったことないけど、便利な機能があるんだな

228NAME IS NULL2018/01/26(金) 12:46:04.91ID:pxozcjcA
>>222
後から追加した列だとわかるメリットもあるけどな。

229NAME IS NULL2018/01/26(金) 12:47:20.40ID:pxozcjcA
>>227
それたぶん見かけの問題だと思う。本当にできるとしたら、内部では作り直しをやっているはず。

230NAME IS NULL2018/01/26(金) 13:23:06.33ID:???
>>225
たとえば不動産のテーブル設計とか、カラム数が増えますからねぇ。
個人的に1対1の関係(必ずJOINする)ならテーブルを分ける必要ないと思います。
それは正規かと違うような。

>>226
会社で順番が重視されるとかはないかと。
ただ個人的に>>203のように思うだけなんで。

>>228
テーブル設計書に追加したカラムはどれか明記してますからね。
それでも確かに末尾に追加した方がわかりやすいとは思います。

DBはMySQL、PostgreSQL、SQLiteぐらいしか知らないので
SQL ServerとかAccessとかはどうかわかりません。
だから私の質問が「こいつ何言ってんだ?」レベルに感じたのだと思います。

231NAME IS NULL2018/01/26(金) 14:12:40.47ID:???
>>230
>たとえば不動産のテーブル設計とか、カラム数が増えますからねぇ。

ここ詳しく

232NAME IS NULL2018/01/26(金) 15:30:10.66ID:???
不動産のテーブルって言っても色々考えられるけどな
不動産販売会社の物件管理とか
賃貸マンションの入居者管理とか
あるいは資産としての不動産管理とか

233NAME IS NULL2018/01/26(金) 15:58:11.99ID:???
これも見た目だけの話になるんだろうけど、PKは先頭にないと違和感があるw

234NAME IS NULL2018/01/26(金) 16:21:41.44ID:???
カラムの見た目の位置が気になるのはSELECT *した時だけでしょ?
あとはDESCしたときか
設計書上は途中の場所に書いておいて、DB上は末尾に追加しとくでいいじゃん

あと業務要件で都度カラムが増えるのはさすがに設計がおかしい

235NAME IS NULL2018/01/26(金) 16:28:53.58ID:???
わかる

236NAME IS NULL2018/01/26(金) 20:41:14.34ID:???
実カラム名書くようなレベルの設計書が実テーブルのカラム順序と違うのはないわ

別にどんな分野でもいいけど、要件が変わってないのにカラム増えるのはさすがにおかしい
要件変更があれば当然増える事もあるだろう

237NAME IS NULL2018/01/26(金) 20:45:05.81ID:gcOPp+C3
コーダーにとっては詳細設計が要件だという驚愕の真実w
てか物理設計て言葉くらい覚えようねw

238NAME IS NULL2018/01/26(金) 21:53:37.57ID:HiY2mRrM
【株FX】 トレーダーが経済A級戦犯 ≪朝生ゴミ、経済成長は宗教≫ 世界2/3貧困を救済しろ 【NEET】
http://rosie.5ch.net/test/read.cgi/liveplus/1516959000/l50

239NAME IS NULL2018/01/30(火) 17:06:10.21ID:???
やりすぎ防犯パトロール、特定人物を尾行監視 2009年3月19日19時7分配信 ツカサネット新聞
http://headlines.yahoo.co.jp/hl?a=20090319-00000026-tsuka-soci

この記事で問題になった通称やりすぎ防パトは、創価学会と警察署が引き起こしていたようです

掻い摘んで説明すると

・創価学会は、町内会や老人会、PTA、商店会等の住民組織に関し、学会員が役員になるよう積極的に働きかける運動を
 90年代末から開始し、結果、多くの住民組織で役員が学会員という状況が生まれた

・防犯パトロールの担い手は地域の住民と住民組織で、防犯活動に関する会議や協議会には、住民組織の代表に役員が出席する為
 防犯活動や防パトに、創価学会が間接的に影響力を行使可能となった

・防パトは住民が行う為、住民が不審者や要注意人物にでっち上げられるトラブルが起きていたが
 創価学会はその緩さに目をつけ、住民組織を握っている状況を利用し、嫌がらせ対象者を不審者や要注意人物にでっち上げ
 防パトに尾行や監視、付き纏いをさせるようになった

・防パトは地元警察署との緊密な連携により行われる為、創価学会は警察署幹部を懐柔して取り込んでしまい
 不審者にでっち上げた住民への嫌がらせに署幹部を経由して警察署を加担させるようになった

・主に当該警察署勤務と考えられる創価学会員警察官を動かし、恐らく非番の日に、職権自体ないにもかかわらず
 私服警官を偽装させて管轄内を歩いて回らせ、防犯協力をお願いしますと住民に協力を求めて回り
 防犯とは名ばかりの、単なる嫌がらせを住民らに行わせた(防犯協力と称し依頼して回っていた警察官らの正体は恐らく所轄勤務の学会員警察官)
 ※これに加えて防犯要員が同様のお願いをして回る

・こうして防犯パトロールを悪用し、住民を欺いて嫌がらせをさせつつ、創価学会自体も会員らを動員し、組織的な嫌がらせを連動して行った

つまり警察署に勤務する学会員警察官、警察署幹部、創価学会が通称やりすぎ防犯パトロールの黒幕

詳細は下記スレをご覧下さい
やりすぎ防犯パトロールは創価学会と警察署の仕業だった
https://rio2016.5ch.net/test/read.cgi/bouhan/1516500769/

240NAME IS NULL2018/02/13(火) 16:59:54.49ID:???
>>230
1対”0 or 1”は積極的に分割すべきかどうか検討した方がいいぞ
特にデータ量の多いテーブルは

意図的に非正規化した場合を除けば
カラム数が100を超えるようなテーブルは
本来別途管理すべきエンティティが埋もれてることが大半

241NAME IS NULL2018/02/14(水) 03:12:25.25ID:kUpzGWTP
>>230
テーブルは意味のあるまとまりで作るのであって1:1だから、ひとつのテーブルにまとめてしまうのはかえって、同じテーブルのカラム同士の関連がわからなくなる。

242NAME IS NULL2018/02/14(水) 13:23:36.19ID:???
☆ 日本の、改憲をしましょう。現在、衆議員と参議院の両院で、
改憲議員が3分の2を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆

243NAME IS NULL2018/02/15(木) 19:48:19.21ID:L39WhMJw
>>241
俺はおまえ、の日本語がわか、らなくなる

244NAME IS NULL2018/02/20(火) 15:44:48.62ID:???
DBになったからといって、なにが違うの
順次編成、ISAM VSAM
DB

項目つけるだけでしょ
それと関連性

245NAME IS NULL2018/02/20(火) 17:15:24.81ID:???
>>244
扱いやすさが桁違い

Comparison of DB2 and VSAM
http://search400.techtarget.com/tip/Why-DB2-is-better-than-VSAM

246NAME IS NULL2018/02/20(火) 19:14:03.16ID:???
さすがにSAMとISAMでは違うだろ
(M)ISAMでちゃんと設計できるならそのままRDBに持っていける気はするけど

新着レスの表示
レスを投稿する