リレーショナル・データベースの世界
序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記：その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み
ChatGPTを使ってDDLからER図をすばやく作成する - Taste of Tech Topics
最近、酢を飲むと健康に良いという話を聞き、頑張って毎日飲んでいるkonnoです。 何となくですが、朝の目覚めは良くなっている気がしますよ！ 今回はデータベース設計に欠かせないER図を、ChatGPTを使ってDDL（Data Definition Language：SQLのデータ定義言語）から簡単に作成できるのか試してみたいと思います。 サンプルとなるDDLを用意 DDLのサンプルとして、以下のMySQL公式サイトで公開されている従業員データベースを利用します。 dev.mysql.com 従業員データベースに必要なファイル類一式は、上記サイトで紹介されている以下のGithubリポジトリから、 "test_db-master.zip"としてダウンロードできます。 github.com ダウンロードしたtest_db-master.zipには、従業員データベースを設定するために必要なDDLとし
データマート開発プロジェクトを通して気づいたメンテナンスしやすいクエリの書き方｜rossokuno
マネーフォワード 分析推進室 アナリティクスエンジニアの奥野です！ 私は、現在ビジネスユーザーが使いやすいデータマート開発プロジェクトに携わっており、その中でdbt Coreを使ったデータパイプラインの構築を行っています。データアナリスト1名、アナリティクスエンジニア2名の合計3名で開発を進めています。 このブログでは、そのデータマート開発プロジェクトにおいて、メンテナンスしやすいクエリを作るためのアイデアが出てきたので共有したいと思います。 伝えたいことは大きく以下の2つです。 SQLリンターSQLfluffを入れるとそれなりに分かりやすいクエリになる リンターではカバーできない分かりやすい書き方のアイデア では早速紹介していきます！ SQLリンターSQLfluffを入れるとそれなりに分かりやすいクエリになるSQLfluffというSQLリンターがあります。すでに日本語でも紹介されている記
史上最強のデータベース、SurrealDB - Qiita
SurrealDBというRust製データベースを知ったので紹介します。このデータベースはすごいです。リレーショナル、ドキュメント、グラフ、あらゆる種類のデータ構造を扱うことができ、かつインメモリ、単一ノード、分散環境、全てで動かすことができます。さらにHTTPやWebSocketによるアクセスと柔軟なユーザ認証、認可機能とがDB本体に内包されており、ブラウザから直に接続するWebDBとしても使えます。とにかくなんでもできる夢のデータベースといった感じです。 特徴 機能を挙げていたら多くなりすぎたので、特に面白い部分を挙げます。 配列やオブジェクトをネストした複雑なデータ構造を持てるのに、レコードリンクという機能によりリレーションに対応していてしかもSQLやMongoDBより簡潔にクエリが書ける。 スキーマレスで各レコードには任意のフィールドを持てるが、必要ならスキーマを定義することもできる
君はまだ平成のアーキテクチャを使ってるのか？僕はFirebaseと令和の時代に行くぞ。 - Qiita
Help us understand the problem. What is going on with this article? メリークリスマス！ この記事はFirebase Advent Calendar 2019の25日目の記事です。 これはなに？ この1年、本を書いたり勉強会で登壇したりいろいろやってみた結果を振り返ってみると、本当に多くの人がFirebaseにふれるようになったなぁと思います。圧倒的な開発者体験の良さをもってバックエンドの関心事を一手に引き受け、アプリケーション開発を劇的に高速化してくれるソリューションとして、Webアプリでもモバイルアプリでもバックエンド第一の選択肢として確固たる地位を確立しつつあるのではないでしょうか。 それ自体はとてもいいことなのですが、Firebaseの強さを活かすためのアーキテクチャに関するアイデアはあまり表に出てきていないのではな
mybatis-spring-boot-starterの使い方 - Qiita
今回は2015年11月にバージョン1.0.0がリリースされ、2016年4月19日に1.1がリリースされたmybatis-spring-boot-starterの使い方を紹介します。 MyBatisをSpring Boot上で使う際は、mybatis-springから提供されているSqlSessionFactoryBeanやSqlSessionTemplateのBean定義を開発者が行う必要がありましたが、mybatis-spring-boot-starterの登場によりこれらのBean定義は自動コンフィギュレーションによって解決されます まずは、実際にmybatis-spring-boot-starterを利用して簡単なCLI(Command Line Interface)アプリケーションを作ってみます 。 Note: 2019/7/16: 追記 JDK 13で導入予定(現時点ではPrev
SQLで羃等にDBスキーマ管理ができるツール「sqldef」を作った - k0kubun's blog
sqldefのリポジトリ github.com これは何か Ridgepoleというツールをご存じでしょうか。 これはRubyのDSLでcreate_tableやadd_index等を書いてスキーマ定義をしておくとそれと実際のスキーマの差異を埋めるために必要なDDLを自動で生成・適用できる便利なツールです。一方、 で言われているように、Ridgepoleを動作させるためにはRubyやActiveRecordといった依存をインストールする必要があり、Railsアプリケーション以外で使う場合には少々面倒なことになります。*1 *2 そこで、Pure Goで書くことでワンバイナリにし、また別言語圏の人でも使いやすいよう、RubyのDSLのかわりに、誰でも知ってるSQLでCREATE TABLEやALTER TABLEを書いて同じことができるようにしたのがsqldefです。 使用例 現時点ではMy
Barman（PostgreSQL PITR 補助ツール）
Barman とは PostgreSQL のPITR（ポイントインタイムリカバリ）を簡単に管理してくれるツールです。 PITRとはバックアップ／リストア方式の一つで、過去の指定した時点の状態に復元することが可能です。PITRは、データベースクラスタの物理コピー（ベースバックアップと呼びます）を取得し、以降のデータ変更が書き出される WALファイルを継続的に保存する（保存したものをWALアーカイブやアーカイブログと呼びます）ことで実現されます。現在稼働しているデータベースクラスタを障害やオペレーションミスから復旧したい場合には、保存していたベースバックアップにWALアーカイブを適用することで、ベースバックアップ取得時点からWALアーカイブが適用できる限りの任意の時点に復元することができます。 PITR は PostgreSQL のバックアップ方式としてよく用いられる手法ですが、DB 管理者が
タウンワーク90万原稿の掲載を支えるレガシーバッチパフォーマンスチューニング #devsumi #devisumiD
2019/02/15 Developers Summit 2019での、森廣の講演資料になります
Living with legacy systems
デブサミ2019 14-A-6 「レガシーのいい感じの付き合い方」
DB スキーマ設計のガイドライン - Qiita
この記事は、2011年頃に書かれた Yii framework サイトの wiki 記事 Guidelines for good schema design の翻訳です。 もともとは Yii 1.1 のために書かれたものですが、Yii 2, Yii 3 にもそのまま適用可能ですし、もっと広く、アクティブ・レコードのような ORM 一般に通用する内容であろうと思われます。つまり、以下の文章中の "Yii" という名前は、あなたが使っている任意のフレームワークの名前に置き換えてもよい筈です。 はじめに 事実上すべての Yii アプリケーションはデータベースの上に構築されます。Yii はデータベースの取り扱いにおいて非常に柔軟ではありますが、以下に述べる設計上の選択をすれば、そうでない場合に比べて、ものごとがより一層都合良く進みます。 最初に、ごく大まかに言うと、Yii アプリケーションではアク
GraphQLとRESTfulについて今日考えてたこと Backend for Usecase/Resourceについて - 余白
DISCLAIMER: これは本当にただのメモ書きで、これがベストプラクティスだとかいう話ではないので、同じようなことを考えてる人いたら今度議論しましょうよ、って程度の話の種。 GraphQLを使うべきスポット、RESTfulが好ましいスポットについて今日ぼんやり考えていて、なんとなく言語化ができる気がするので文字起こししてみる。 Backend for UsecaseとBackend for Resource バックエンドのAPIには2種類あって、 「データ」を構成する「リソース」を提供するもの アプリケーションの「ユースケース」がもつシナリオのなかで登場する「データ」部分を埋めるためのもの を区別することが必要そう、と思っている。 まず前者を Backend for Resource (BFR)と呼ぶことにする。これはわかりやすくて、これはまさしくRESTfulそのもの。 RDBやそう
分散システムの限界について知ろう
↓↓↓↓訂正あります。↓↓↓↓ 2018/07/02に株式会社エフコード社内で行われた勉強会のスライドです。 訂正版(随時更新中): https://docs.google.com/presentation/d/15HOMfAbtdWwO48njcB8IdkN3kVAMu3wsmZo0O3S-f_4/edit?usp=sharing 専門家による資料・専門家向けの資料ではありません。自分自身で学習し、論文・文献等を読解してまとめた内容となります。間違い等あるかもしれませんが、あれば是非コメント頂ければと思います。 【訂正事項】 スライド16: 誤：たった一つのプロセスが故障しただけでも有限時間で合意できない 正：たった一つのプロセスが故障しうるだけでも有限時間で合意できない スライド20: 誤: 重要: あるschedule σ1, σ2 がdisjoint (nodeが被ってない) なら
分散システムとしての #Elasticsearch - Taste of Tech Topics
こんにちは、 @snuffkin です。 こちらはDistributed computing Advent Calendarの12日目の記事となります。 qiita.com Elasticsearch6.0も登場し、使っている方も増えつつあるのではないかと思います。 進化が速く、どんどん機能が増えていますが、基本的なところを押さえるのも重要と考えています。 先日、Acroquest社内勉強会で「Elasticsearch as a Distributed System ～分散システムとしてのElasticsearch～」と題して Elasticsearchの分散システムとしての側面について話しました。 Elasticsearch as a Distributed System from Satoyuki Tsukano www.slideshare.net 資料の内容 ノードの種類 シャー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - schemalex/schemalex: Generate difference sql of two mysql schema
GitHub - ridgepole/ridgepole: Ridgepole is a tool to manage DB schema. It defines DB schema using Rails DSL, and updates DB schema according to DSL. (like Chef/Puppet)
GitHub - gimenete/dbdiff: Compares two postgresql or mysql databases and prints SQL commands to modify the first one in order to match the second one
Welcome to pg-diff documentation
db tech showcase Tokyo 2015 プレゼンテーションスライド | Insight Technology, Inc.
事例から見るNoSQLの使い方 - db tech showcase Tokyo 2015 2015/06/11
