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

**NAME IS NULL** · 2017/05/22(月) 16:38:31.52

語れ

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

**NAME IS NULL** · 2018/01/25(木) 17:22:02.78

気になるもクソもRDBってのは「集合」を扱うもんなの
そして集合には順序なんて概念はないの

**NAME IS NULL** · 2018/01/25(木) 17:23:25.83

>>199
もちろん、ユーザに見せるときにはSQLではなくプログラミング言語で調整しているよ

**NAME IS NULL** · 2018/01/25(木) 17:25:46.44

じゃ、テーブル設計書作ってるときとかphpMyAdminを利用してるときとかなんでも良いです。
順序がないけど順序を視覚化しているツールを使っている時に、
カラム名やデータ型が異なる順番で並んでると気になりませんか？

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

**NAME IS NULL** · 2018/01/25(木) 17:30:24.66

>>203
気にはなるけどリレーショナルデータベースとはそうしたもんだ

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

**NAME IS NULL** · 2018/01/25(木) 17:32:15.39

>>204
つまり、
>>196の要件で「携帯電話」を追加したい場合、
id,name,address,telephone,comment,date,mobilephone

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

**NAME IS NULL** · 2018/01/25(木) 17:38:50.08

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

**NAME IS NULL** · 2018/01/25(木) 17:39:52.94

205はリレーショナルモデルの勉強をした方が良いのでは

**NAME IS NULL** · 2018/01/25(木) 18:03:00.90

エクセルに切り替えれば解決

**NAME IS NULL** · 2018/01/25(木) 18:05:52.91

順序にこだわるのは、>>203にも書いたとおり、
仕様書なり設計書なりを見た人物（自分含む）が
誤認しないか？正しく伝わるか？と思ったからです。

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

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

**NAME IS NULL** · 2018/01/25(木) 18:08:44.34

たとえばMySQL「AFTER」というコードが有るのも、「指定位置に追加したい」
という需要があったからこそ用意されたのではないでしょうか？
そうでなければ末尾でも良いわけです。

**NAME IS NULL** · 2018/01/25(木) 18:12:05.73

何のためにほとんどのアプリでUIが別途あると思っとる
そういう整形はフロントエンドの役目

**NAME IS NULL** · 2018/01/25(木) 18:13:18.10

>>209
まさかと思うけど
リレーショナルデータベースをphpMyAdminで直接編集しようとしている？
(そんなはずはない、と思いたい)

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

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

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

**NAME IS NULL** · 2018/01/25(木) 18:19:21.67

teratailを見ると以下のように回答している人がいました。

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

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

**NAME IS NULL** · 2018/01/25(木) 18:26:41.60

>>213 DBの実装に依存する
これまでの君の主張は見た目の順序のことだから
的外れの突っ込みだぞ

**NAME IS NULL** · 2018/01/25(木) 18:41:36.73

どうしてもやりたきゃ
別テーブル作ってそこにコピーしてリネームすれば

**NAME IS NULL** · 2018/01/25(木) 18:54:38.23

それこそ無駄じゃないですか？

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

**NAME IS NULL** · 2018/01/25(木) 19:13:05.84

DBに依存する処理だけど、やりたければやれば良いのだと思うよ
>>216 の動機はやはり的はずれだと思うけど
みんなが言っているようにアプリで対応するのじゃ駄目なの？

**NAME IS NULL** · 2018/01/25(木) 19:36:37.81

まあしかし、心情的には理解できなくもない
最終更新日や削除フラグ(笑)の後ろに項目あると、ああ、あとから追加したんだなと切ない気持になる

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

**NAME IS NULL** · 2018/01/25(木) 19:37:01.16

>>216
また馬鹿が調子こいてでまかせ言ってたみたいだなw
迷惑かけてすまんのうw

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

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

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

**NAME IS NULL** · 2018/01/25(木) 19:40:17.60

>>219
「DBに順序という概念はない」は216だけが言ってるんじゃないかな
そして標準SQLでは, 途中に列を挿入する処理は存在していないんじゃない？

**NAME IS NULL** · 2018/01/25(木) 19:52:49.07

>>220
少なくとも質問者である私は「DBに順序という概念はない」って言っていません。
回答者がそうおっしゃるから、自身の知識を改めただけです。

**NAME IS NULL** · 2018/01/25(木) 19:55:46.45

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

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

**NAME IS NULL** · 2018/01/25(木) 19:57:33.96

>>221
>>216でそう言っているよね？正解は>>219の通りだけど

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

**NAME IS NULL** · 2018/01/26(金) 02:01:50.61

>>222
MySQLでしか通用しない小手先をもって「こうするべき」なんて言うやつおらんて

**NAME IS NULL** · 2018/01/26(金) 02:15:25.24

カラム数が100近くになるというのは、そこからしてメンテ困難な状態でしょう
順序に拘る、気にするよりも設計に問題がなかったか見直した方が良いように思う

**NAME IS NULL** · 2018/01/26(金) 02:18:38.09

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

**NAME IS NULL** · 2018/01/26(金) 02:35:15.34

>>218
心情的にはこれに同意だな

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

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

**NAME IS NULL** · 2018/01/26(金) 12:46:04.91

>>222
後から追加した列だとわかるメリットもあるけどな。

**NAME IS NULL** · 2018/01/26(金) 12:47:20.40

>>227
それたぶん見かけの問題だと思う。本当にできるとしたら、内部では作り直しをやっているはず。

**NAME IS NULL** · 2018/01/26(金) 13:23:06.33

>>225
たとえば不動産のテーブル設計とか、カラム数が増えますからねぇ。
個人的に1対1の関係（必ずJOINする）ならテーブルを分ける必要ないと思います。
それは正規かと違うような。

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

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

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

**NAME IS NULL** · 2018/01/26(金) 14:12:40.47

>>230
>たとえば不動産のテーブル設計とか、カラム数が増えますからねぇ。

ここ詳しく

**NAME IS NULL** · 2018/01/26(金) 15:30:10.66

不動産のテーブルって言っても色々考えられるけどな
不動産販売会社の物件管理とか
賃貸マンションの入居者管理とか
あるいは資産としての不動産管理とか

**NAME IS NULL** · 2018/01/26(金) 15:58:11.99

これも見た目だけの話になるんだろうけど、PKは先頭にないと違和感があるw

**NAME IS NULL** · 2018/01/26(金) 16:21:41.44

カラムの見た目の位置が気になるのはSELECT *した時だけでしょ？
あとはDESCしたときか
設計書上は途中の場所に書いておいて、DB上は末尾に追加しとくでいいじゃん

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

**NAME IS NULL** · 2018/01/26(金) 16:28:53.58

わかる

**NAME IS NULL** · 2018/01/26(金) 20:41:14.34

実カラム名書くようなレベルの設計書が実テーブルのカラム順序と違うのはないわ

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

**NAME IS NULL** · 2018/01/26(金) 20:45:05.81

コーダーにとっては詳細設計が要件だという驚愕の真実w
てか物理設計て言葉くらい覚えようねw

**NAME IS NULL** · 2018/01/26(金) 21:53:37.57

【株FX】　トレーダーが経済A級戦犯　≪朝生ゴミ、経済成長は宗教≫　世界2/3貧困を救済しろ　【NEET】
http://rosie.5ch.net/test/read.cgi/liveplus/1516959000/l50

**NAME IS NULL** · 2018/01/30(火) 17:06:10.21

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

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

掻い摘んで説明すると

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

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

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

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

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

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

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

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

**NAME IS NULL** · 2018/02/13(火) 16:59:54.49

>>230
1対”0 or 1”は積極的に分割すべきかどうか検討した方がいいぞ
特にデータ量の多いテーブルは

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

**NAME IS NULL** · 2018/02/14(水) 03:12:25.25

>>230
テーブルは意味のあるまとまりで作るのであって1：1だから、ひとつのテーブルにまとめてしまうのはかえって、同じテーブルのカラム同士の関連がわからなくなる。

**NAME IS NULL** · 2018/02/14(水) 13:23:36.19

☆ 日本の、改憲をしましょう。現在、衆議員と参議院の両院で、
改憲議員が３分の２を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆

**NAME IS NULL** · 2018/02/15(木) 19:48:19.21

>>241
俺はおまえ、の日本語がわか、らなくなる

**NAME IS NULL** · 2018/02/20(火) 15:44:48.62

DBになったからといって、なにが違うの
順次編成、ISAM VSAM
DB

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

**NAME IS NULL** · 2018/02/20(火) 17:15:24.81

>>244
扱いやすさが桁違い

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

**NAME IS NULL** · 2018/02/20(火) 19:14:03.16

さすがにSAMとISAMでは違うだろ
(M)ISAMでちゃんと設計できるならそのままRDBに持っていける気はするけど

**NAME IS NULL** · 2018/02/21(水) 23:27:11.35

順次SAMは総なめしたり
Trに振りまら混ぜたりたいへんだから違うのはわかりますが

相当まーじとか冗談言っていた時代が懐かしいｗ

**NAME IS NULL** · 2018/02/21(水) 23:29:59.45

振り分け

**NAME IS NULL** · 2018/04/07(土) 17:29:50.05

経理システムは一つの仕分けテーブルに借方も貸方も詰め込んでフラグで分別してると思うけど
これを借方テーブル、貸方テーブルの二つに分けるのはどうだろうか？
デメリットとして処理が複雑になるけど、貸方だけの検索とかがデータが半分になる分だけ速くなりそうだけど。

**NAME IS NULL** · 2018/04/07(土) 17:51:30.32

>>249
インデックスを適切に設定してたらデータ量の倍半分とかではたいした差はでないよ

**NAME IS NULL** · 2018/04/07(土) 18:32:05.17

振替伝票1枚ごとに伝票番号振るとすると、
貸方か借方で違うテーブルに入るのはどうなのかな

**NAME IS NULL** · 2018/04/25(水) 14:23:33.67

マスタデータをJavaServletのアプリケーションスコープ変数に格納して
そこを参照したほうが処理が軽いかと思ったけど、DBが同じサーバー
にある場合はあまり変わらないのかな？

**NAME IS NULL** · 2018/04/25(水) 17:25:06.73

>>252
コンピュータの仕組みを勉強してください。

**NAME IS NULL** · 2018/04/27(金) 19:37:20.55

>>253
未だに末尾の長音符を省略してしまうおじいちゃんは黙っててね

**NAME IS NULL** · 2018/04/28(土) 06:14:34.24

え、逆にIT業界で省略しないとかあるの？
問題起きたことないんか？

**NAME IS NULL** · 2018/04/28(土) 10:38:35.05

>>255
おじいちゃんなの？
そもそも問題ってなに？

**NAME IS NULL** · 2018/04/28(土) 10:56:07.06

>>255
今は2018年ですよ

**NAME IS NULL** · 2018/04/28(土) 11:09:37.85

＞マスターデーターをJavaServletのアプリケーションースコープー変数に格納して

こう？

**NAME IS NULL** · 2018/04/28(土) 12:28:02.71

それ面白いの？

**NAME IS NULL** · 2018/04/28(土) 13:02:27.58

なあ、俺と知識をシェアーしようぜ！

**NAME IS NULL** · 2018/04/28(土) 13:29:20.62

わざわざ慣用に逆らう必要性説明できる？
もし取引先が慣用を知らなかったらどんな奴らが仕事してんのか不安になるよな

**NAME IS NULL** · 2018/04/28(土) 14:03:16.12

別にコンピューターだろうがコンピュータだろうが気にしないけど慣用に従ってないじゃねーかとか言うような取引先だと国の指針やMSの方針変更も知らなくて大丈夫か？って不安になるわ w

http://www.mext.go.jp/b_menu/hakusho/nc/k19910628002/k19910628002.html
http://www.atmarkit.co.jp/news/200807/25/microsoft.html

**NAME IS NULL** · 2018/04/28(土) 14:11:16.33

>>262
これと個々のIT企業との関連は？

**NAME IS NULL** · 2018/04/28(土) 14:14:36.67

>>263
関係ないと思う

って言うような取引先なんて余計に不安になるだろ

**NAME IS NULL** · 2018/04/28(土) 14:15:31.78

>>264
なぜ？

**NAME IS NULL** · 2018/04/28(土) 14:24:05.30

最近思うんだけどみんな無知な奴を相手にし過ぎ。
みんなが知ってる常識レベルの事知らないで、
さも、それが当たり前の様に振る舞ってる奴とかいるじゃん。
そういう奴に正しい事を教えてくれと請われるならともかく、
わざわざ教える事無いって。

常識知らずに正しい事教えても常識を真似するだけで理解してないし、
表面的に真似されると常識知らずを判別出来なくなる。
馬鹿は馬鹿のままでいてもらった方が関わりを避けれる。
無駄に教えちゃいかんと思う。

**NAME IS NULL** · 2018/04/28(土) 14:32:49.38

無知には教えたくない()教えたがりのジレンマwいじらしいのおwww

**NAME IS NULL** · 2018/04/28(土) 14:32:59.28

>>266
常識はそれぞれの主観に基づく上に
そんなことしても見栄の張り合いで専門板なんて成り立たないぢゃん。。
このスレに限って見てもまともに進行したのは初心者の質問に自称上級者が答えるときだけよ
あとは不毛な罵り合い非建設的なやり取りだけ
ある種のクッションを設けるために多様な人が必要ですわよ

**NAME IS NULL** · 2018/04/28(土) 16:27:41.26

長音符号はJIS的にはどっちでもいいはずだけど、
つける派にもつけない派にも妙なこだわりがある人が混じってる
文化庁のやつにも慣例に応じて省略可能とちゃんと書いてある
https://ging.co.jp/tips/57001/
http://www.bunka.go.jp/kokugo_nihongo/sisaku/joho/joho/kijun/naikaku/gairai/honbun06.html

**NAME IS NULL** · 2018/04/28(土) 16:36:14.55

知ってるか？ここ実はDB設計スレなんだぜ……

**NAME IS NULL** · 2018/04/28(土) 18:13:36.79

>>270

おおっっっそれは知らなかった！

**NAME IS NULL** · 2018/05/12(土) 07:21:49.70

共同ツール 1
https://seleck.cc/685

https://trello.com/
ボードのメニュー → Power-Upsから拡張可能 Slack DropBoxなど
Trello Chrome拡張機能　elegant
ttp://www.kikakulabo.com/service-eft/
trelloのオープンソースあり

共同ツール 2
https://www.google.com/intl/ja_jp/sheets/about/

共同ツール 3
https://slack.com/intl/ja-jp
https://www.dropbox.com/ja/
https://bitbucket.org/
https://ja.atlassian.com/software/sourcetree
https://sketchapp.com/extensions/plugins/
ttp://photoshopvip.net/103903

ttps://goodpatch.com/blog/sketch-plugins/

**NAME IS NULL** · 2018/05/25(金) 21:13:08.94

論理削除否定派のヤツが設計したシステム
取引先からの依頼データなど大事なデータ平気でdeleteしてるんだが、そもそも他人が作ったデータを跡形もなく消せて、その消した証拠すら残さないとかシステムとして間違ってる。

**NAME IS NULL** · 2018/05/25(金) 21:15:53.50

削除データの扱い方、議論始めると荒れるんだけど

**NAME IS NULL** · 2018/05/25(金) 21:21:20.27

だけどその議論はいつも、ユーザーデータはみんなで使ってる共有資産であるという重要な視点が抜けてる。

**NAME IS NULL** · 2018/05/25(金) 21:24:01.69

君の個人情報もみんなで共有しよう

**NAME IS NULL** · 2018/05/25(金) 21:26:30.82

そんなゴミはいらん
おまえ一人で共有しとけ

**NAME IS NULL** · 2018/05/25(金) 21:34:37.41

>>273
必要ないからdeleteしてるんでしょ？

**NAME IS NULL** · 2018/05/25(金) 21:54:12.06

>>278
それが必要だったから大トラブル

**NAME IS NULL** · 2018/05/25(金) 22:01:35.26

つまり必要なデータを削除してしまったマヌケを論理削除の問題だと勘違いしてしまったもっとマヌケな>>273
というおはなしやな
少々笑えた

**NAME IS NULL** · 2018/05/25(金) 23:10:40.85

postgresで一切vacuumしないで運用したらいいんじゃね。time machineで任意の時点に戻れるぞ。

**NAME IS NULL** · 2018/05/25(金) 23:17:56.83

>>273
同じテーブルに残す方がわかりにくい。

**NAME IS NULL** · 2018/05/25(金) 23:20:27.43

>>281
実際はどのRDBMSでもそんな簡単な使い方をしていないから、それをやることはほぼない。

**NAME IS NULL** · 2018/05/25(金) 23:25:58.38

具体例で考えた方が良いと思う
例えば商品マスターだと、在庫切れやメーカー廃番でも削除する事はしていない
会員情報の場合だと、会員登録申請、会員情報更新、退会をそのまま反映している
退会の場合は、一定期間保留しその後物理削除している
商品販売時は、販売後にサポートが必要だったりするため、
退会とはリンクせずそのまま販売履歴として残している

**NAME IS NULL** · 2018/05/25(金) 23:47:38.82

>>284
言いたいことは理解できるが、データ量と更新・参照頻度を書かずにものを言っても意味がない。

単にリレーショナルデータベースの知識、SQLの理解が足らないことで論理削除状態にしていることがある。

**NAME IS NULL** · 2018/05/26(土) 00:50:49.12

>>280
制御が不十分で、仕掛中のデータが削除できてしまいデータ不整合となった。
どこから発生したか出元の不明なデータだけが存在する状況で、大混乱。
結局前日のバックアップから発生元のデータをサルベージしたって話・・

**NAME IS NULL** · 2018/05/26(土) 06:48:26.89

>>286
いやそれ削除フラグ云々以前のレベルやろ...

**NAME IS NULL** · 2018/05/26(土) 07:04:47.67

延々と削除フラグの話を続けるんだね w

**NAME IS NULL** · 2018/05/26(土) 08:11:25.72

>>287
削除フラグはともかく、物理削除はダメだろって話。
消しちゃいけない理由は、後付けで増えていくことが多いから、考慮漏れがあると死ねる

**NAME IS NULL** · 2018/05/26(土) 08:32:39.78

制約も知らんアホは黙ってなよ... w

**NAME IS NULL** · 2018/05/26(土) 08:41:20.21

考慮漏れで問題を起こす可能性を考えたらなんでもありだろう。
削除フラグを見落として処理するコードが混入していて大混乱、とかね。

**NAME IS NULL** · 2018/05/26(土) 09:43:20.38

>>291
それでも跡形もなく消えるよりマシ
少なくとも原因はすぐわかる。

**NAME IS NULL** · 2018/05/26(土) 10:04:04.12

面会記録は跡形もなく消します

**NAME IS NULL** · 2018/05/26(土) 19:39:28.98

レコードの削除をしても他のテーブルで保管するのが普通。

同じテーブルにためたがるのは、古めかしいデータそのものがどういう状態かを自ら示すという発想から来ているもの。

**NAME IS NULL** · 2018/05/26(土) 21:36:41.88

>>294
ソース

**NAME IS NULL** · 2018/05/26(土) 21:55:41.58

>>295
集合演算子を知らない。

**NAME IS NULL** · 2018/05/26(土) 22:16:19.76

>>296
何言ってんのこいつｗｗｗ

**NAME IS NULL** · 2018/05/26(土) 23:00:10.53

削除して良い要件と、削除方法は別の話なんだが
そして削除フラグは、データの削除ではなく単なる状態変更の場合があるって話

これが理解できない奴が削除フラグの話をかきまわしてるだけ

**NAME IS NULL** · 2018/05/26(土) 23:11:28.11

継続して議論したいなら、コテハン付けるなりトリップ表示させなよ

**NAME IS NULL** · 2018/05/26(土) 23:21:53.44

削除フラグの話題にすらついてこれない人がどうしてこのスレにいるの？