アンチパターンから学ぶ RDBの正しい設計 / learn-from-failure-2■PHPerKaigi 2019の登壇資料です - https://phperkaigi.jp/2019/ - https://fortee.jp/phperkaigi-2019/proposal/328896eb-c084-41c9-847f-f0512a538811 ■前作 - 失敗から学ぶ、RDBの正規化の話 - https://soudai.hatenablog.com/entry/learn-from-failure-1
もし間違ってDROP DATABASEしてしまったら – area[nothing] : diary
2007/ 01 02 03 04 05 06 07 08 09 10 2006/ 01 02 03 04 05 06 07 08 09 10 11 12 2005/ 01 02 03 04 05 06 07 08 09 10 11 12 2004/ 01 02 03 04 05 06 07 08 09 10 11 12 2003/ 01 02 03 04 05 06 07 08 09 10 11 12 2002/ 01 02 03 04 05 06 07 08 09 10 11 12 2001/ 01 02 03 04 05 06 07 08 09 10 11 12 2000/ 01 02 03 04 05 06 07 08 09 10 11 12 1999/ 01 02 03 04 05 06 07 08 09 10 11 12 1998/ 01 02 03 04 05 06 07 0
QuarkusでDBと接続するWebAPI作ってみた - Qiita
目的 巷で話題のQuarkusの使い勝手を確認した内容のまとめを残します。 Get Started だけは物足りなかったのでローカルで立てたPostgreSQLをHibernateで操作するRESTのWebAPIにしてみました。 事前準備 Mavenプロジェクト QUARKUS - CREATING YOUR FIRST APPLICATIONを先に完了させておきます。 プロジェクトの状態はこんな感じです。 $ tree ./ ./ ├── pom.xml ├── quarkus_quickstart.iml └── src ├── main │ ├── docker │ │ └── Dockerfile │ ├── java │ │ └── com │ │ └── dsert │ │ └── quickstart │ │ ├── Greet
RDS for PostgreSQL で変更すべきパラメータチューニング - そーだいなるらくがき帳
※追記(タイトルにRDSと書いたがPostgreSQL限定である） RDSはデフォルトでパラメータをチューニングされているものの、本番でそれなりに使うにはチューニングが必要。 そこで最初にある程度チューニングしておくべき場所を記載していく。 AWSのパラメータについては下記を参考。 docs.aws.amazon.com デッドロックの検査間隔 soudai.hatenablog.com deadlock_timeout はデフォルトは1000msになっている。 1秒はPostgreSQLのデフォルトなので短い。 10秒以上と書いているが弊社の場合は40秒にしている。 これは明確な基準値を持って決めてるわけでは無く、pg_stat_database.deadlocks の値が今までずっと0なので強気に付けている。 checkpointの値 Google検索すると checkpoint_se
【MySQL】照合順序とは？ - Qiita
照合順序（collations ）が違うためSQLのjoinで失敗。 これを機会に照合順序について調べてみる。 SQLSTATE[HY000]: General error: 1267 Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '=' MySQLは文字コードとソート順を持っていて、ソート順の部分がCollationとよばれている。(文字コードの部分はCharacter Set) 比較するときには文字コードだけでなくてCollationが一致するかどうかを比較する(順序が合わないと比較できない)。 ので、JOINしようとするとエラーになる。 DB単位、テーブル単位、カラム単位で設定可能。 照合順序の意味 例えば cp932_japanese
テーブルやカラムのCollationは揃えよう - 41から始めました
元ネタはMySQL Casualのslack この辺以降 それを見て、 そういや自分も2年前(DB移行時)にこれ調べたなー 社内メンバーに改めてちゃんと周知しよう なんか記事書くか という軽い備忘録的な感じ。 ちなみに、揃えないとどうなるか？ slackにもあったように、 インデックスが効かない！(抽出はできる) 試しにテストテーブルを作る(個人の趣味が多分に含まれているのは気にしないこと) 使った環境はMySQL8.0.13 CREATE TABLE `test1` ( `test1_id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'testID1', `test1_name` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL COMMENT '名前', `test1
[講義] データベース設計の講義資料を公開します - YoheiM .NET
こんにちは、@yoheiMuneです。 G's ACADEMY TOKYOさんでいくつか講義を担当させていただいているのですが、新しくデータベース設計の講義を行ったので、そのスライドを公開したいと思います。 講義内容 この講義は、初めてプログラミングを学んだ方向けで、卒業制作で作るアプリケーションのデータベース設計ができるようになることを目標にしています。特に論理設計を扱い、アプリケーションで扱うデータ構造を読み解いて理解できるようになります。 論理設計では以下の項目を扱います。 データの理解 エンティティの定義 リレーションシップの定義 データ項目の定義 列の定義 少しでも参考になればと思い、もし気になった方はチラッと見てみて頂けたら嬉しいです。 編集後記 データベース設計についていざ講義を作ろうとするとなかなかアイデアがまとまりませんでした。いつもやっていることをいざ明文化しようとする
![[講義] データベース設計の講義資料を公開します - YoheiM .NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/c8f8646166b23c50571aee45678e8d77a47d399e/height=288;version=1;width=512/https%3A%2F%2Fwww.yoheim.net%2Fimage%2F546.png)
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策｜ハイクラス転職・求人情報サイト AMBI（アンビ）
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
JJUG CCC 2017 Springで論理削除フラグをどうにかするための話をしてきました 【FOLIOスポンサー】 - itohiro73’s blog
JJUG CCC 2017 Springで、「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」という話をしてきました。 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 from Hiroshi Ito 今回の登壇は、株式会社FOLIOのスポンサーセッションです！FOLIOについてはこちらの入社エントリー記事もご参考ください。Toggetterは下のリンクから。 togetter.com 世の中のみなさんが「論理削除フラグ」を使いたくなるモチベーションとしては、実は「削除」ではなく別のビジネスロジックを実装したいだけであることがほとんどだと思います。 たとえば論理削除フラグという名の死亡フラグ - @ledsun blogというエントリを参考にさせていただくと、下記のような要件の例があります。 ・社員が退職（・転
PostgreSQLは標準でバックスラッシュをエスケープしない仕様になった
PostgreSQL9.1の仕様変更にて、デフォルト時の設定として、standard_conforming_stringsがonとみなされるようになりました。この仕様変更により、デフォルト設定でのPostgreSQLは、バックスラッシュをエスケープする必要がなくなり、ISO規格のSQLと同様のエスケープルール（シングルクォートを重ねるのみ）となります。 PostgreSQLの文字列リテラルは、元々MySQL同様に、バックスラッシュをエスケープする仕様でした。その後、リリース8.1にて、設定パラメータ standard_conforming_strings が追加され、この値が on の場合、バックスラッシュをエスケープしない（ISO規格と同様の）仕様となりました。従来のリリースでは、standard_conforming_stringsを指定しない場合offとみなされていました。これは、後
DB 設計時のサイズ見積り[最新版] - Qiita
こんにちは、すっかり秋ですね！@yone098 です。 みなさんDBの設計してますか？ DB設計時のサイズ見積り 以前はてなダイアリーで書いた記事は5年前のものであり、リンクが切れているものがあるので最新版として MySQL, PostgreSQL, Oracle, SQLServer におけるDB設計時のサイズ見積りをまとめ直しました。 URL内のバージョン表記を変えると以前のバージョンの情報になります。 MySQLは、あまり情報に変化は無かったので Excel でマクロなどを作成して自社で自動算出出来るようにするのが良いと思います。 データタイプごとに必要な要求ストレージが決まっているのでレコードサイズが決まり、あとは要件次第で何レコードになるかを予測します。 データタイプごとに必要な記憶容量 テーブルの最大サイズ関連 http://dev.mysql.com/doc/refman/5
![DB 設計時のサイズ見積り[最新版] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/f42e24e40ddeea81bc76c98ccc1f982252cd6b3c/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9REIlMjAlRTglQTglQUQlRTglQTglODglRTYlOTklODIlRTMlODElQUUlRTMlODIlQjUlRTMlODIlQTQlRTMlODIlQkElRTglQTYlOEIlRTclQTklOEQlRTMlODIlOEElNUIlRTYlOUMlODAlRTYlOTYlQjAlRTclODklODglNUQmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWM5ZmIwOTA1Y2UwNjU4NDA0MzRmOTZlMmI2NDFlMGU1%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB5b25lMDk4JTQwZ2l0aHViJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1iZDkzOTdmMGQ3NWNhMGM4M2I3NmMxNjM4ODQ2OWQxMA%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-QWJieQ%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D6f836c4a275f61471b9e3f73ef123bda)
4ステップで作成する、DB論理設計の手順とチェックポイントまとめ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「達人に学ぶDB設計」、「SQLアンチパターン」を読んだのでDB設計をする流れとその過程でのチェックポイントをまとめてみました。 今回は本に載っているものの中でも特に重要そうな部分に絞ってみました。 さらに詳しいことを知りたい方は本を購入してみてください。個人的には達人に学ぶDB設計徹底指南書のほうがおすすめです。こちらだけあれば十分だと思います。 DB設計には大きく分けて論理設計と物理設計の二つがありますが、今回はアプリケーション開発でメインとなる論理設計の部分に焦点をあてて説明をします。 一番最後にチェックポイントだけをま
Rails だって硬いデータベース設計をしたい！そんなあなたに贈る Tips 4 選 - peroli Developer's Blog
2016 - 09 - 09 Rails だって硬いデータベース設計をしたい！そんなあなたに贈る Tips 4 選 list Tweet こんにちは、ペロリのサーバサイドエンジニアの @a_suenami です。 今回は Ruby on Rails アプリケーションにおけるデータベース設計についてちょっとご紹介したいと思います。 データベース設計してますか？ みなさん、データベース（以下、DB）設計していますか？Scaffold したときにできた migration ファイルをそのまま使ったりしてませんよね？ Ruby on Rails （以下、 Rails ）は CoC（Convention over Configuration: 設定より規約）を強く提唱している フレームワーク であり、それによって得られる恩恵も大きい反面、かなり強めに設計の自由度を束縛されるという特徴もあります。特に
マイクロにしすぎた結果がこれだよ！
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
トランザクションの設計と進化
3. Copyright©2016 NTT corp. All Rights Reserved. トランザクションの基本 トランザクションとは： データに対する一連の操作を一つにまとめた単位の事 トランザクションマネージャとは： 複数のトランザクションがACIDを守って走るよ うに管理する機構 A: Atomicity 結果がAll-or-Nothingとなる事 C: Consistency 一貫性を守る事 I: Isolation 過程が他の処理から見えない事 D: Durability 結果が永続化される事 Consistentな状態空間 Inconsistentな状態空間 Diskが取りうる全ての状態の空間 Atomicな遷移 4. Copyright©2016 NTT corp. All Rights Reserved. 何らかの実行順(スケジュール空間) 直列に実行した場合の結果
このRDBについて私は驚くべき闇を見つけたがそこを発表するにはネットは怖すぎる
YAP(achimon)C::Asia Hachioji 2016midの資料です。
PostgreSQLは寿司ビール問題を解決する（unicode 6問題について）
TwitterでMySQL と寿司ビール問題ってのが話題になりました。 MySQLと寿司ビール問題 結論から言うとMySQLでは指定されてた文字コードによっては あれ？ MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる？ SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。 — とみたまさひろ (@tmtms) 2014, 12月 22 ってなる話です。 詳細については前述のブログで触れられていますがMySQLとしてはバグではなく仕様だそうです。 でふーんって思って見てたら MySQLの「寿司とビール」問題、面倒臭いね。「PostgreSQLならそんなことはないよ」って言われたら使うの検討するレベルにイヤな感じ。 — 長谷川智希@とむぞう (@tomzoh) 2015, 3月 23 と長谷川さんが仰ってるのを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://engineering.mercari.com/entry/2017/12/18/deadlock
データベース技術の羅針盤
ネットゲームデータベース設計むかしばなし、あるいはとんでもないMMORPGの設計の話: 不倒城