DB設計を語るスレ 10 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>219
「DBに順序という概念はない」は216だけが言ってるんじゃないかな
そして標準SQLでは, 途中に列を挿入する処理は存在していないんじゃない? >>220
少なくとも質問者である私は「DBに順序という概念はない」って言っていません。
回答者がそうおっしゃるから、自身の知識を改めただけです。 返信が前後しますが、>>218さんみたいな意見があれば「やっぱり切なくなりますよね」
って思うだけです。自分も切なくなるから質問したわけですし。
かといってテーブル作り直すレベルまでもとめていません。
何度も書きますが、MySQLだとカラム同士の間に挿入できるわけですから。
ググっても「こうするべき」的な情報もないので質問したわけですが、
よくわからなくなってきました。もう半端な知識で適当に行きます。
みなさん、色々ありがとうございました。 >>221
>>216でそう言っているよね? 正解は>>219の通りだけど
>>199 や >>201 や >>204 も, みんな同じことを言っていると思う >>222
MySQLでしか通用しない小手先をもって「こうするべき」なんて言うやつおらんて カラム数が100近くになるというのは、そこからしてメンテ困難な状態でしょう
順序に拘る、気にするよりも設計に問題がなかったか見直した方が良いように思う >>222
カラムの順番が重要視される会社で開発しているとしよう
同僚のコードはテストを通っていたが、マージはリジェクトされてしまった
あなたが先にマージしたコードのせいで、カラムの位置が不適切になったためだ
同僚はコードを修正する事より、規約を考えたあなたを殴る事を優先するだろう >>218
心情的にはこれに同意だな
実務的な話をするなら、工程による。設計中なら、気の済むようにしたらいいけど、運用後の仕様変更だと、間に挟む為だけにテーブル作り直すとは客に説明できん..
MySQLは使ったことないけど、便利な機能があるんだな >>222
後から追加した列だとわかるメリットもあるけどな。 >>227
それたぶん見かけの問題だと思う。本当にできるとしたら、内部では作り直しをやっているはず。 >>225
たとえば不動産のテーブル設計とか、カラム数が増えますからねぇ。
個人的に1対1の関係(必ずJOINする)ならテーブルを分ける必要ないと思います。
それは正規かと違うような。
>>226
会社で順番が重視されるとかはないかと。
ただ個人的に>>203のように思うだけなんで。
>>228
テーブル設計書に追加したカラムはどれか明記してますからね。
それでも確かに末尾に追加した方がわかりやすいとは思います。
DBはMySQL、PostgreSQL、SQLiteぐらいしか知らないので
SQL ServerとかAccessとかはどうかわかりません。
だから私の質問が「こいつ何言ってんだ?」レベルに感じたのだと思います。 >>230
>たとえば不動産のテーブル設計とか、カラム数が増えますからねぇ。
ここ詳しく 不動産のテーブルって言っても色々考えられるけどな
不動産販売会社の物件管理とか
賃貸マンションの入居者管理とか
あるいは資産としての不動産管理とか これも見た目だけの話になるんだろうけど、PKは先頭にないと違和感があるw カラムの見た目の位置が気になるのはSELECT *した時だけでしょ?
あとはDESCしたときか
設計書上は途中の場所に書いておいて、DB上は末尾に追加しとくでいいじゃん
あと業務要件で都度カラムが増えるのはさすがに設計がおかしい 実カラム名書くようなレベルの設計書が実テーブルのカラム順序と違うのはないわ
別にどんな分野でもいいけど、要件が変わってないのにカラム増えるのはさすがにおかしい
要件変更があれば当然増える事もあるだろう コーダーにとっては詳細設計が要件だという驚愕の真実w
てか物理設計て言葉くらい覚えようねw やりすぎ防犯パトロール、特定人物を尾行監視 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/ >>230
1対”0 or 1”は積極的に分割すべきかどうか検討した方がいいぞ
特にデータ量の多いテーブルは
意図的に非正規化した場合を除けば
カラム数が100を超えるようなテーブルは
本来別途管理すべきエンティティが埋もれてることが大半 >>230
テーブルは意味のあるまとまりで作るのであって1:1だから、ひとつのテーブルにまとめてしまうのはかえって、同じテーブルのカラム同士の関連がわからなくなる。 ☆ 日本の、改憲をしましょう。現在、衆議員と参議院の両院で、
改憲議員が3分の2を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆ >>241
俺はおまえ、の日本語がわか、らなくなる DBになったからといって、なにが違うの
順次編成、ISAM VSAM
DB
項目つけるだけでしょ
それと関連性 さすがにSAMとISAMでは違うだろ
(M)ISAMでちゃんと設計できるならそのままRDBに持っていける気はするけど 順次SAMは総なめしたり
Trに振りまら混ぜたりたいへんだから違うのはわかりますが
相当まーじとか冗談言っていた時代が懐かしいw 経理システムは一つの仕分けテーブルに借方も貸方も詰め込んでフラグで分別してると思うけど
これを借方テーブル、貸方テーブルの二つに分けるのはどうだろうか?
デメリットとして処理が複雑になるけど、貸方だけの検索とかがデータが半分になる分だけ速くなりそうだけど。 >>249
インデックスを適切に設定してたらデータ量の倍半分とかではたいした差はでないよ 振替伝票1枚ごとに伝票番号振るとすると、
貸方か借方で違うテーブルに入るのはどうなのかな マスタデータをJavaServletのアプリケーションスコープ変数に格納して
そこを参照したほうが処理が軽いかと思ったけど、DBが同じサーバー
にある場合はあまり変わらないのかな? >>252
コンピュータの仕組みを勉強してください。 >>253
未だに末尾の長音符を省略してしまうおじいちゃんは黙っててね え、逆にIT業界で省略しないとかあるの?
問題起きたことないんか? >>255
おじいちゃんなの?
そもそも問題ってなに? >マスターデーターをJavaServletのアプリケーションースコープー変数に格納して
こう? わざわざ慣用に逆らう必要性説明できる?
もし取引先が慣用を知らなかったらどんな奴らが仕事してんのか不安になるよな >>263
関係ないと思う
って言うような取引先なんて余計に不安になるだろ 最近思うんだけどみんな無知な奴を相手にし過ぎ。
みんなが知ってる常識レベルの事知らないで、
さも、それが当たり前の様に振る舞ってる奴とかいるじゃん。
そういう奴に正しい事を教えてくれと請われるならともかく、
わざわざ教える事無いって。
常識知らずに正しい事教えても常識を真似するだけで理解してないし、
表面的に真似されると常識知らずを判別出来なくなる。
馬鹿は馬鹿のままでいてもらった方が関わりを避けれる。
無駄に教えちゃいかんと思う。 無知には教えたくない()教えたがりのジレンマwいじらしいのおwww >>266
常識はそれぞれの主観に基づく上に
そんなことしても見栄の張り合いで専門板なんて成り立たないぢゃん。。
このスレに限って見てもまともに進行したのは初心者の質問に自称上級者が答えるときだけよ
あとは不毛な罵り合い非建設的なやり取りだけ
ある種のクッションを設けるために多様な人が必要ですわよ 論理削除否定派のヤツが設計したシステム
取引先からの依頼データなど大事なデータ平気でdeleteしてるんだが、そもそも他人が作ったデータを跡形もなく消せて、その消した証拠すら残さないとかシステムとして間違ってる。 だけどその議論はいつも、ユーザーデータはみんなで使ってる共有資産であるという重要な視点が抜けてる。 >>273
必要ないからdeleteしてるんでしょ? つまり必要なデータを削除してしまったマヌケを論理削除の問題だと勘違いしてしまったもっとマヌケな>>273
というおはなしやな
少々笑えた postgresで一切vacuumしないで運用したらいいんじゃね。time machineで任意の時点に戻れるぞ。 >>281
実際はどのRDBMSでもそんな簡単な使い方をしていないから、それをやることはほぼない。 具体例で考えた方が良いと思う
例えば商品マスターだと、在庫切れやメーカー廃番でも削除する事はしていない
会員情報の場合だと、会員登録申請、会員情報更新、退会をそのまま反映している
退会の場合は、一定期間保留しその後物理削除している
商品販売時は、販売後にサポートが必要だったりするため、
退会とはリンクせずそのまま販売履歴として残している >>284
言いたいことは理解できるが、データ量と更新・参照頻度を書かずにものを言っても意味がない。
単にリレーショナルデータベースの知識、SQLの理解が足らないことで論理削除状態にしていることがある。 >>280
制御が不十分で、仕掛中のデータが削除できてしまいデータ不整合となった。
どこから発生したか出元の不明なデータだけが存在する状況で、大混乱。
結局前日のバックアップから発生元のデータをサルベージしたって話・・ >>286
いやそれ削除フラグ云々以前のレベルやろ... >>287
削除フラグはともかく、物理削除はダメだろって話。
消しちゃいけない理由は、後付けで増えていくことが多いから、考慮漏れがあると死ねる 考慮漏れで問題を起こす可能性を考えたらなんでもありだろう。
削除フラグを見落として処理するコードが混入していて大混乱、とかね。 >>291
それでも跡形もなく消えるよりマシ
少なくとも原因はすぐわかる。 レコードの削除をしても他のテーブルで保管するのが普通。
同じテーブルにためたがるのは、古めかしいデータそのものがどういう状態かを自ら示すという発想から来ているもの。 削除して良い要件と、削除方法は別の話なんだが
そして削除フラグは、データの削除ではなく単なる状態変更の場合があるって話
これが理解できない奴が削除フラグの話をかきまわしてるだけ 継続して議論したいなら、コテハン付けるなりトリップ表示させなよ 削除フラグの話題にすらついてこれない人がどうしてこのスレにいるの? ちゃんと削除フラグの話題で進めばいいけど>>286とか>>294みたいに頓珍漢なこと持ち出してグダグダになった過去が何回もあるからなぁ w >>298
ステータスならフラグという持ち方は変。 ひとつのレコードにたくさんフラグ項目を持っていて、それを複雑な条件で判断するようなやつは死ねよ! >>304
状態がオン/オフしかないようなものならフラグでおかしくない
>>305
フラグたくさん持ってるとか条件が複雑とか、それが要件なら仕方ない
むしろ全然関係ないフラグをビットフィールドにまとめるほうが迷惑 >>306
>>298 は削除フラグが状態変更と言っている。単に論理削除ではないと言っている。それをただ「削除フラグ」と呼んだら普通は意味がわからない。 >>306
おまえ、ジジイだろ?
そんなわかりにくいデータの持ち方は、リレーショナルデータベースの考え方ではない。 削除フラグの泥沼スレという名前のスレを建ててそこでやれよ。 だいたい削除フラグなんていらないしな。
とにかく汎用機ジジイがリレーショナルデータベースを使うとこうなる。
またはExcelシートだと思っている素人が考えるとこうなる。 >>311
リレーショナルデータベースをExcelと同じようなものと考えている人は多いぞ。 >>305
一つの項目がステータスを表し、0〜9の値を持ち、2と7が削除扱いという設計を見たことがある。
2が取引先からのキャンセル、7がこちら都合のキャンセル。
嫌になった。 毎日の果物の価格を記録するデータベースを作りたいんですがどういうテーブルをつくったらいいですか?とりあえずitemsテーブルに果物の種類とidのカラムを作ります。
毎日の価格はどういうテーブルにしたらいいですか? >>314
itemテーブルはそんなものだろうと思う。
毎日の価格を登録するテーブルというのが、
実際の販売時の価格を取引単位で記録して行くのか、
それとも一定時間での平均価格等を記録して行くのか
もう少し具体的な要件を出してもらう方が良いかと思う >>315
価格というのは市場で取引された価格の高値と安値で1日2つの価格に決まります。 その高値と安値の取得は、システム側でリアルタイムに行うのか、
それとも、一日の最後に取得するものなのか
前者の場合は、そういう記録もとっておき、更新しないとならなくなるよね では、難しく考える必要はない
記録したい項目をテーブルに用意して終わりでしょう ■ このスレッドは過去ログ倉庫に格納されています