はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どうも、記事書くのにちょっとはまっちゃった人です 今日は「本当にあったやらかしDB設計①【R無しRDB】」に続いてまたびっくりしたことを紹介します #囚人番号テーブル 割とみんな使ってしまっているのではないでしょうか どういうことかというと、「XXX001」「XXX002」「XXX003」のようにテーブル名に囚人番号を付けている、ということです ###何が悪いの？？ 皆さん、クラス名や関数名を付けるときに悩んだ経験はありませんか？ 誤用を避けるためや可読性を向上させるためにも名前付けって大事ですよね これは**テーブル名にも同じことが言

どうも、近々引っ越しを考えていたのに在宅勤務が始まって引っ越す意味がなくなった人です 今日は「本当にあったやらかしDB設計④【テストチューニング】」に続いてびっくりしたことを紹介します 「正規化は第三正規化までやればいい！」と誰かが言ってたらしいです 僕の周りにはR無しRDBを見ても何も思わないような人ばっかりなので直接聞いたことはないですが…ｗ しかし、第三正規化まですればいい、というのは嘘です 必要に応じて更に正規化を行う必要があります ほとんどの場合、更に正規化をしたほうが良いです ※詳細について知りたい方は、是非SQLアンチパターンの付録としてついてきている「正規化のルール」を見てください 何が悪いの？？ 正規化という考え方に縛られてはいけません 一番重要なのはデータの不整合を防ぎつつ、データの冗長性も減らすことです 問題 第三正規化までやればいい！、という考えに縛られていると、冗

どうも、GWのほうが用事が詰まって忙しかった人です(外出はしていないのですが…) 今日は本当にあったやらかしDB設計③【ロジカルクエリー】に続いてびっくりしたことを紹介します #テストチューニング 案件説明とかを受けると出会うことが意外と多いです どういうことかというと、本番より明らかにレコード数の少ないテーブルに対してチューニングを行う、ということです ###何が悪いの？？ データベースではとある計算に基づいてオプティマイザー(DBの脳みそのような部分)が実行計画を立てます 今主流なのはコストベースオプティマイザーです コストベースオプティマイザーでは、レコード当たりの平均容量や、テーブルのレコード数に基づいて計算を行い、実行計画を立てます レコード数が全く違うテスト用テーブルに対してチューニングを行うとどのようなことが発生するでしょうか ###問題 まず、チューニングといっても種類があ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どうも、最近夏バテ気味の人です 今日は[「本当にあったやらかしDB設計⑦【ステートフルDB】」] (https://qiita.com/bouitengineer12/items/325fec42c1c3bb385c64)に続いてびっくりしたことを紹介します #ファンクションDB そもそもファンクション(関数)とは… あるデータを渡すとあるデータを返す処理のことです 同じデータを渡せば、同じ結果が返ってくるという特徴があります ファンクションを利用する側は実際にどのような処理を行っているかを気にする必要がなく、inputとoutputだ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どうも、最近コンビニ飯に飽きてきた人です 今日は「本当にあったやらかしDB設計⑤【第三正規化病】」に続いてびっくりしたことを紹介します #見えない削除フラグ そもそも削除フラグとは何でしょうか レコードに専用のカラムを用意し、その値が0であれば未削除、1であれば論理削除、とする手法のことです しかし、削除フラグは良い方法ではありません 下記でかなり詳細にわかりやすく説明されているので是非見てください SQLアンチパターン 幻の第26章「とりあえず削除フラグ」 削除フラグは手間を増やしたりバグになる可能性を持ってはいますが、注意していれば

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どうも、最近システムエンジニアの出てくる海外映画をよく見る人です 今日は「本当にあったやらかしDB設計②【囚人番号テーブル】」に続いてびっくりしたことを紹介します #ロジカルクエリー これ、本当に良く見かけます どういうことかというと、本来アプリケーションで処理するべき機能を無理矢理クエリーに詰め込む、ということです ###何が悪いの？？ DBというのはデータという商品の入った、ただの倉庫です RDMBSという倉庫番が居るため、倉庫に入れる前に商品を検査することができます 倉庫番(RDBMS)は商品を倉庫に入れたり、取り出したりすること

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どうも、最近満員電車に殺意を抱くようになった人です 今日は本当にあったやらかしDB設計⑥【見えない削除フラグ】に続いてびっくりしたことを紹介します #ステートフルDB そもそもステートフルDBとは何でしょうか ステートフルDBとは、状態遷移をDBが管理していることです DBの値を0や1にすることによってアプリケーションの挙動を変えようとしてしまっています 更に、更新頻度が異常に高いです 削除フラグについては前回も触れていますが、削除フラグに留まらず、○○フラグというものは手法としてはかなり悪手です 下記で説明されているので、是非見てみて

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どうも、IT業界は4年目だけど開発はあんまりやったことがなかった人です 独学でDBとアプリ周りを勉強して最近開発現場へと行くことになったのですが、僕でもわかるようなやばいような事がかなりゴロゴロあって唖然とする毎日です(運が良いのか悪いのか…) 今日はそんな中の一つを紹介したいと思います #R無しRDB これには本当にびっくりしました どういうことかというと、外部キーをひとつも使ってなかったのです 分析系DBなのかと思いきや調べたり聞いたりして確認したところがっつり処理系、しかもコアな部分…ｗ データの不整合を許せない部分なのに外部キー

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?