[B! データベース] ghostbassのブックマーク

DB設計書の管理が楽になるDBML入門 – DBMLの書き方,dbdiagram.io, dbdocs の紹介 – | SIOS Tech. Lab

こんにちは！サイオステクノロジーの安藤浩です。DB 設計書の生成が容易にできるDBMLをご紹介します。DBMLの入門として、DBMLの書き方、ER図生成方法、Github actionsでCIを実行して閲覧する方法をご紹介させていただきます。 DBMLとは DBMLは DataBase Markup Language の略でDB構造を定義するために設計された言語です。 DB構造に焦点を当てており、可読性の高い言語です。 dbdiagram.io や dbdocs.io などを利用することでDBドキュメントの生成が可能です。コードベースで図を生成できる点でPlantUMLと似ていますね。 DBMLの書き方テーブルの書き方まずはテーブルの定義の例をもとにDBMLの記法を紹介していきます。users というテーブルを作成してみます。コードは以下のようになります。Table users

ghostbass 2024/05/22

第一印象: DDLでよくない？

リンク

勘でリレーションを張っていないか？ - Qiita

はじめに今回は外部キーを張るときに最低限意識したいことについて書きました。何か間違えがあったり、もっとこういうところも意識してますという人がいたらコメントお願いします。この記事で伝えたいこと ①リレーションシップ先のデータを消したときに同時にリレーションシップ元のデータが消えても自然な状態を作る ON DELETE CASCADEをうまく利用できる状態を作るつまり親子関係を正確に表現する。リレーションシップ先は親テーブル、リレーションシップ元は子テーブルを意味しています。 ②データを作成するときのことを考えてデータの生成順序がおかしくならないように外部キーを張る ③関連を表現するときに中間テーブルを利用したほうが良い場面がある注意下記【例を交えながら説明】の説明に出てくるテーブル設計に関しては、上記の【この記事で伝えたいこと】の①と②と③の項目に対して想像しやすいように、理解

ghostbass 2023/01/29

なんか微妙/指導要録の保管期間的に先生の情報はおいそれと消せない、とかも

リンク

MySQLでIN句の中に大量の値の入ったクエリがフルスキャンを起こす話 - freee Developers Hub

こんにちは、freee Developers Advent Calendar 2021、19日目のid:shallow1729です。昨日はtdtdsさんで︻マジで︼サイバー演習シナリオの作り方︻怖い︼でした！障害訓練後に攻撃方法を解説された時はリアリティの高さに驚きました。僕はMySQLを使っていて発生した不思議な挙動の調査の話をしようと思います。今回問題となったクエリ今回話題にするクエリは以下のようなシンプルなものです。 SELECT * FROM hoge WHERE id IN (...) MySQLのパラメーター次第ですが、デフォルトの設定だとこのIN句の中の値の数が数万になると適切なインデックスが用意されていてもフルスキャンが発生する事がありました。このクエリがテーブルのほとんどのレコードを網羅するような場合や高速でレコードを大量にinsertして統計情報が追いつかないケー

ghostbass 2021/12/19

IN句の中の値の数が数万＜ちょっと考えにくいけどどういうユースケースなんだろ

リンク

なぜ「共有データの整合性」が重要なのか？　ゲームにおけるサーバーサイド設計のいろは

2019年5月22日、﹃神姫PROJECT﹄などソーシャルゲームの企画・開発を手がける株式会社テクロスが主催するイベント﹁TECH x GAME COLLEGE﹂が開催されました。第20回となる今回のテーマは﹁正しいゲーミング Web サーバーの作り方﹂。株式会社gumi、CTOの幾田雅仁氏が、自身の経験をもとにさまざまな事例について解説します。後半パートとなる今回は、ゲーム本体のデータストア設計のコツや、言語・サービスなどの技術選定における考え方について語りました。講演資料はこちらゲーム本体のデータストア設計のコツ幾田雅仁氏︵以下、幾田︶‥続いて﹁RDBMS＋NoSQL﹂です。先ほどと同じ流れですが、ゲーム本体のデータストアの設計のコツを1つ挙げると﹁共有データの整合性を担保する﹂ことです。ゲームの本体以外のマイクロサービスって、裏側はNoSQLがメインデータでぜんぜんOKなんで

ghostbass 2019/07/25

リンク

データベースにRDBを選択するときの注意事項について考える（追記あり） - Qiita

2019年6月20日追記‥ この度は、本ブログにて技術的に誤った記事を掲載したことをお詫び申し上げます。具体的には以下の通りです。一方的にRDBがスケールしないという技術的根拠が薄い内容となっていました。 RDBとAmazon DynamoDB︵以下、DynamoDB︶/NoSQLデータベースを要件に応じて適切に選択するという内容になっていませんでした。また、本来考慮すべきアプリケーションの設計やデータアクセスパターンに言及しておらず、RDBのデメリットの部分にのみ焦点を当てる内容となっていました。 DynamoDBの具体的な活用やDynamoDBを使う上での注意点についても触れられていない不明瞭な記載でした。当初の記事の目的としましては、特定のユースケースをサンプルとして、最適なデータベースを選択頂くことでした。近日中に正確な技術記事を掲載させて頂きます。以下の内容は修正前の内容と

ghostbass 2019/06/19

ただMap Reduceする程度の要件にRDB使う必要はないし、完全なACIDが必要なのにシャーディングの一部がしくじるようなデータベースは選択できないし/ そこそこの検索性能とそこそこのコレクション処理のためのRDB。

リンク

データベースとSQLの業務スキルレベル　判別表　（５段階） - 主に言語とシステム開発に関して

スキルチェックの目次へリレーショナル・データベースを利用したシステム開発の，簡易スキルチェックのための調査表。印刷用。データベース・エンジニアのレベルを測定する。レベルは，0から4までの5段階。︵0︶非エンジニア︵1︶初学者︵入門書を学習してゆく段階︶︵2︶ノーマル︵基礎的な知識があり，ある程度の動くものを作れるようになった段階︶︵3︶中級者︵開発プロジェクトで1人月としてカウントできる水準︶︵4︶上級者︵メインPG/メンターとして，主設計を任せられる水準︶ Webアプリのプロジェクト開始時に作業振り分けをするにあたって，新規メンバ全員にこれを渡して回答してもらうという用途を想定。なお，開発上のスキルをチェックする事が主眼なので，DBAとしての技量はあまり考慮しない。下記で﹁自分に当てはまる項目が最も多いレベルが，自分の属するレベルである﹂とする。 ※ただし，

ghostbass 2018/10/23

ちょろっとチェックしてみたが初学者レベルにも達しなかった…

リンク

PostgreSQL 11が正式リリース。ハッシュパーティショニングやJITコンパイルによる高速化、ストアドプロシージャでのトランザクションサポートなど

PostgreSQL 11が正式リリース。ハッシュパーティショニングやJITコンパイルによる高速化、ストアドプロシージャでのトランザクションサポートなど発表文ではPostgreSQL 11の主な新機能を次のように説明しています。 PostgreSQL 11 provides users with improvements to overall performance of the database system, with specific enhancements associated with very large databases and high computational workloads. Further, PostgreSQL 11 makes significant improvements to the table partitioning system, adds

ghostbass 2018/10/19

リンク

SQLスタイルガイド · SQL style guide by Simon Holywell

概要全般推奨非推奨命名規則通則表列別名、相関名ストアド・プロシージャ統一的接尾辞問合せ文予約語空白類インデント望ましい形式 Create文データ型の選択デフォルト値の指定制約とキー非推奨設計付録予約語リファレンス SQLスタイルガイド︵日本語訳︶日本語訳について日本語訳は誤訳や原文の最新版に追随していない恐れがあります。誤訳や改善点があれば、GitHubのissueまたはpull requestを使用するか、Twitterでお知らせください。翻訳: 久利史之 @nkuritw概要このガイドラインは利用の他、forkしたり、自分自身のものに改変したりすることができます。ここで大事なのはスタイルを選択しそれを踏襲することです。変更の提案やバグの修正にはGitHubのissueまたはpull requestを使用してください。このガイドライン

ghostbass 2018/09/25

"川"スタイルは整形が面倒(=整形ツール必須)

リンク

MySQLのFLOAT型を使う理由が見つからない件 - hnwの日記

MySQLのデータ型としてFLOAT型という型があるのですが、これを採用するのは混乱の元ではないか？と感じたので、その詳細を紹介します。そもそもこの話のきっかけは﹁MySQLで6桁までの小数点を丸めずに扱うならFLOAT型を使うべき理由﹂という記事が目に止まったことです。それなりに人気を集めている記事のようですが、私の読んだ限りではFLOAT型を使うだけの根拠が文中から読み取れず、さらに類似する一次情報や英語記事が全く見つからなかったので、真偽が怪しい情報だと感じました。その後、MySQL上で実験したりCソースコードを読んでみたりした結果、私の得た結論は真逆のものになりました。MySQL警察の方や浮動小数点数警察の方、追試や反論など頂けると助かります。 MySQLのFLOAT型とは MySQLのFLOAT型は原則としてIEEE754浮動小数点数単精度型︵32bit︶で実現されます*1。

ghostbass 2017/12/22

最近読んだ記事か本かで「正確さと精密さは違う」って書いてあったな。float(またはdouble)に要求されるのは8桁なり15桁なりの精密さであって、正確さではない。正確さが必要なのは言語DB問わずdecimal使う。

リンク

東芝、社会インフラなどで使われているNoSQL「GridDB」をオープンソースで公開。インメモリでビッグデータの高速処理が可能

東芝は、これまでGridStoreとしてエネルギー管理システムなどの社会インフラで利用されてきた商用のNoSQLデータベースを、﹁GridDB﹂としてオープンソース化したことを発表しました。 GridDBはキーバリュー型を拡張したキーコンテナ型のデータモデルで、時系列データや2次元、3次元の空間データもサポートするNoSQL型データベース。データをストレージではなくサーバーのメインメモリに配置し、インメモリで処理することで、ペタバイトクラスのビッグデータでも高速に処理が可能。ノードを追加するだけで容量や性能を拡張、縮退できるスケールアウト機能、マスタスレーブ型とピアツーピア型の特長を合わせ持つハイブリッド型クラスタ管理方式の自律制御クラスタ管理により、SPOF︵Single Point of Failure‥単一障害点︶を排除した高い可用性などが特長です。東芝はオープンソース化の狙い

ghostbass 2016/03/02

Apacheライセンスっぽい。そのうち試す・・・違うAGPLか

リンク

2007-03-02

いちばんインパクトがあったのが、T字形ER手法はやっぱりサロゲートキーを認めていないとわかったこと。「コンピュータの内部で勝手に取った連番は、いちばん手に負えない」とのこと。何が問題かというと「そういうものがあると、組織変更の時とかに大変なことになる」のだそうだ。何で？て話。で、休憩時間に質問に行ったわけだ。「サロゲートキーがあるとコード体系の変更に強くなるんじゃないんでしょうか」と。正美氏の答えはこう：ダメなコードからはダメな構造しか出てこない。ダメなコードに別名を付けてみてもダメな構造は変わらない。構造を変えないと。「サロゲートキーは構造の問題を温存する働きをするだな」「サロゲートキーが邪魔になってシステムに実装できなくなる『外界の変化』というものがあるのだな」と。 http://d.hatena.ne.jp/tgk/20070228#1172679908 うーむ、問題

ghostbass 2015/09/10

商品コードとか従業員番号とかが一体どこから湧いて出てくるのか、と。

リンク

はてなブックマーク

タグ

関連タグで絞り込む (6)

データベースに関するghostbassのブックマーク (11)

お知らせ

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

今週のはてなブックマーク数ランキング（2024年7月第1週）

月間はてなブックマーク数ランキング（2024年6月）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス