【IT】ヤフー 個人情報を別のIDに誤って上書き 最大約39万件 [ムヒタ★]

こっわ

>>25
正解

ソフトバンクはテレビに広告料を支払っているから報道されません

>>157
googleはYahooほど事故起こしていない印象はある。

これ具体的にはヤフオクで問題が出てくるってこと？

>>137
>>109が言ってることがそのqiitaに書いてある事なんだが・・・
話に付いてこれてない事がよく分かった

qiitaに書かれている問題点の解決法は>>110が書いてくれてるぞ
単純にリレーションキーが足りてないだけ

qiitaのレベルの回答ならオラクルマスターは当然として、IPAのデータベース試験すら受からんよ

履歴を辿れるという「機能」の話と
>>96みたいな糞「実装」の話の区別もついてないバカに何を言っても無駄だよ
>>139でId書きまくってるのに予想通り>>126に触れてなくて笑う
何を指摘されてるかも理解できてない低レベルなのがバレバレw

　 Λ,,,Λ
　(ミ・ω・)バ韓国の標準仕様だな

情報の漏洩は大丈夫なのか？
中国アプリだけじゃなくラインも省庁や市町村が使うの禁止して欲しい

ソフトバンクYahoo
最初だけ金をばらまいて安く見せかけるのは、朝鮮ハゲの常套手段だよ。

目先の安さにつられて情弱が集まってきたら一気に料金を値上げするって手口。

ソフトバンクケータイも高かろう悪かろう。何度だまされたら気づくんだよ。

糞過ぎる

なんでこんなことになるの？
スーパーSEの皆さん教えて

>>7
情報が第三者に漏れてはいない
なので賠償はない

数年後にも同じようなミスは起こるだろう
人為的ミスはある事だから

Ｂｙヤフー無関係者

あ、送られて来た種には気お付けろよｗ

Yahoo Japanグループは信用してないわ。
グループ企業のYJFXに個人情報保護法に基づく個人情報削除を依頼したけど、技術的に一つも削除できない、の一点張り。
監督省庁の金融庁に苦情いれた。

こいつら何回目だろホント

日本は凄いwww個々だよな全部乗っかってくるなよ無能ども　

>>96 だけど、qiita みたいな素人のチラシの裏を引き合いに出すのを
含めて、予想以上に馬鹿ばかりなのが良〜く判った。

実務経験あり:
ID:62L+/uXz
ID:akLEYRNo

設計経験なしか、糞システムしか関わったことなし:
ID:46BijMVC
ID:NqDjLjgD
ID:+vvd4GTX
ID:WMSEt2ZJ (==ID:oKSwdnyo ?)

未経験か、学生、グラムなんぼで売られる兵隊:
ID:C3OyDI9d
ID:ZPMYK1PA
ID:NPL9vNdh
ID:HvCJ9kon

かな？

プロマネだったら外すとかイキる、馬鹿な船頭がリーダーシップ(w
発揮するから炎上するのも当然だわな。

ID:WMSEt2ZJ
> 顧客情報の管理とその履歴管理は別
> 履歴の参照頻度はそれほど高くないから通常別テーブルにするのはほぼ常識

いったいどこの常識やら？
こういう勘違いの馬鹿が仕切るから、糞システムが出来上がる。

つーか、DB設計の基礎を知らん奴がDB作るから、日本企業はBIツールとか普及せんのよな
BIツールのDBにぶっ込むデータの整理整頓だけで凄い工数取られるから
このスレ見ただけでも闇深すぎる・・・

Yahooは定期的にこういうの起こすね

なんかの証拠が残らないように不具合起こしてるのかな

>>104
insertとかupdateの話ではなく、ビジネスとして最低限必要な情報を整合性を保持しながら
いかに少ないデータ量で保持するかってのがDB設計の基本なんよ

例えば、注文履歴を6ヶ月保持するとして、俺が今日引越しして住所変えたら、3ヶ月前に
注文した注文の発送先も新しい住所になっていいのかって話
（注文履歴テーブルに住所を持つのはアホ過ぎて論外）

実は現場では純粋なDB技術よりこういう部分の知見の方が求められるんだけど、設計やった
ことのない若手とか、下流工程専門の安いエンジニアはそういうスキルがなくて、Webでも
手に入る小手先の技術に目が行きやすい

大量のUpdate コマンド流し込んだんだろうな。そしてやばいとなってDBでロールバック。
目に浮かぶようだ。

他山の石とし、俺も気をつけよう。

>>110
レコード数が変更回数倍になるんだぞ
しかも最新以外のレコードはほとんどアクセスされない
俺がマネージャならそんな設計する奴いたらメンバから外すわw

IDのカラムを意図的に上書きしたなら分かるが、個人情報のカラムを他のと入れ替えるってらことは、別にTableが存在してるって事か？

何をキーにして上書きした？

>>159
そりゃそうだがたいていのECサイトだとそこら辺の構成はたいして変わらんよ
まれに>>96みたいなアホが出てくるだけ

ヤホーなんかに住所や電話番号を登録するのが
そもそも情弱すぎて、もうね

>>174
> 世の中、実際にそういうシステムがあるんだよ。
だからそんなアホ設計出してきて俺の方が偉いとか言ってるアホがお前ってことな

> お前がシッタカだろう。　基本的(wってなんだよ。　文系脳か？
特殊な例を出してきてマウントしてくるお前みたいな基地外よけだよ

> 物理設計やったことないだろ？
お前がな
変化しないマスター情報を履歴と一緒に管理するとか物理設計考えたら普通は採用しないよ

> データベースやテーブル自体に、マスタ/トランザクションの区別はない。
今更何を言ってるんだよw
そんなこと言い出したらデータなんて 0/1 の集合でしかない

> ごく普通のECサイトで、顧客情報でも商品情報でも何でもいいから、お前の言う
> 「基本的に変化しないマスタに記録するデータ」って何だ？
要件次第だけど顧客情報なら Id, 生年月日, 氏名, 性別, etc やね
まあ最近だと性別なんかも変化するかもなw

これはありえないな
なんかおかしなことやろうとしてミスった可能性あるな
最近、どうもここは個人情報の管理が心配
ポータルサイトとしてこれ以上使うのは危険な感じすらするな

別のIDに正確に書き込めているなら「それは仕様です」で言い逃れできるなｗ

>>132
正規化する目的を理解できてないんだなって事だけはよく分かった

履歴のテーブルに同じ情報持つのに、最新情報だけ顧客情報のテーブルにダブらせて持つ理由はないやん
高速化するにしても、ユーザーIDが主キーの顧客情報のテーブルに、履歴テーブルのスーパーキーを
持たせればいいだけ

つーか、ヘッダテーブルとヒストリーテーブルのコンビは王道オブ王道な組み方やで

>>22
JNB?
ペーペー銀行やろ

5万いくらかの商品を注文して
カップ麺のケースが届いた奴ってこれか？

>>162
俺>>161だけど、そんなお前にはこんな絵をプレゼントしてやるよ
https://encrypted-tbn0.gstatic.com/images?q=tbn%3AANd9GcSRhaleUg4Y3bPLPcE3-au1AKI28AJkb-ULew&usqp=CAU

>>120
話のレベルが違いすぎるやで
最低限、第三正規化くらいは勉強してからドヤ顔してもろて

>>121
>>127
履歴管理しない顧客情報DBとか見たことないで
CS、経理、統計分析、障害対応等にも使うからDB情報は時系列も含めて管理するのがセオリーやん
つーか、顧客情報なんかレコード数たいしたことないやろ
通販サイトとかなら、トランザクション発生数で考えれば顧客情報変更より注文とかの方が圧倒的に多いやん

そういえば少し前に、ＳＢＩ証券のサイトにログインするとき、
「もっと安全にｙａｈｏｏＩＤで・・・」とか表示されてたけど、
それを使うと他人の口座にログインできてしまうのか？
俺は使わなかったが、あぶねー　金融庁はどう責任を取るつもりだ！

しかし、トランプのコロナとゆうちょのことしか報道してない

seいきてますか？

わざとする理由って何？

ヤフー最低だな
ヤフーニュースのトップに一日中晒すべき

>>143
>>137
> 履歴を無理矢理正規化しないのは半ば常識だぞ
> 実務やってたらすぐにわかると思うんだが…
主張がブレ過ぎて何が言いたいのか分からなくなってきてるぞ

あと、まさかBronzeを資格としてカウントするとは思わなかったわ
ITパスポートとかCCNAとか持ってても経歴書の資格欄に書かない感覚でいた

>>136
・Ver1.5を開発する時、使い難いVer1.0用DBの転用を諦めて、Ver1.5用のDBを新設する
　（Ver1.0用DBとVer1.5用のDBでデータは重複管理する）
・そのうちVer1.0用DBとVer1.5用のDBのデータ同期が行われなくなる
・そのうち「Ver1.0用DBはデータが古くて信用できないデータだから気を付けろ」とか言われるようになる
・新人が項目の扱いを間違えてVer1.0用DBの古いデータでVer1.5用のDBを上書きするバグを作り込む
　（テストではバレない）
・本番障害起こして、Ver1.0用DBとVer1.5用のDBのデータを試験環境に落とした上で、分析かけて
　本来あるべきデータを生成して本番環境にパッチを当てる（もちろん連日残業）
・Ver2.0ぐらいでDBがぐちゃぐちゃだからシステムごと再構築した方がいいよねとか言われてDBを作り直す

この辺までがセットだなｗ

まあでも今回大事に至ってないからいいんじゃないの？
もとに戻せたわけでしょ、こんくらいのトラブルはよくある
個人情報流失ではあるけど、比較的規模は小さいと思う

ひどいなー

先輩！大変です！where句がありません！
系？

ごめんなさい。
要求仕様通りに作るだけな土方の立場をドヤ顔でカミングアウトされたときどんな顔すればいいかわからないの。

>>1
外部からの攻撃より、内部要因の方が圧倒的に多い件

>>1
https://asahi.5ch.net/test/read.cgi/newsplus/1596759990/

人手不足なんだろうな
定期メンテナンス、保守業務のマニュアル化された部分を新人君やスキルの低い人間にやらせてみたらとんでもないヘマをやらかした

そんな感じなんじゃないの？

昔に設計したＤＢ屋さんは、ＤＢ移行のことはこれっぽっちも考えておらんかったｗ

新たに担当したＤＢ屋さんは、既存のＤＢを理解せず扱っていたｗ

まあ、よくある普通のことです。

>>17
そうかと言ってGmail.com の安全性はどうなのよ？