タグ

dbに関するtsuchikazuのブックマーク (14)

  • データベースのドキュメント管理を自動化した話 - estie inside blog

    こんにちは、今回はデータ基盤構築を担当しているmarushoがお送りします。 今日はestieで実践しているデータベースのドキュメント管理方法をご紹介します。 はじめに 独自成長していくデータベースたち 失われたドキュメント どうすれば低コストなドキュメント管理ができるのか そして生まれた、schema collectorという自動化ツール SchemaSpy Mysql diff Priv Page ECS タスクスケジューラ ドキュメントを腐らせない おわりに はじめに estieはオフィスを中心とした不動産データを取り扱うスタートアップ企業です。 estie(オフィス探しサービス)とestie pro(不動産事業者向けデータプラットフォーム)の2つのサービスを運営しています。 詳しくは、こちらの記事をご覧ください。 inside.estie.co.jp estieでは、不動産に関する

    データベースのドキュメント管理を自動化した話 - estie inside blog
  • 2020年現在のNewSQLについて - Qiita

    Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較 NewSQLのコンポーネント詳解 1章から3章までの内容を当記事で解説する。 4章はさらに詳細な技術的解説となり、後編の「NewSQLのコンポーネント詳解」で記述している。 こちらも合わせて一読いただきたい。 1. NewSQLとは何か NewSQLとは、海

    2020年現在のNewSQLについて - Qiita
  • 履歴を持つデータの設計

    酔いどれ設計ナイト2019の発表資料です。

    履歴を持つデータの設計
  • State of SQL Antipatterns in 2017

    2017/07/10 SQLアンチパターンNight Part2 https://connpass.com/event/59946/

    State of SQL Antipatterns in 2017
  • データベースリファクタリングについて話をしてきた #OSO2017 - そーだいなるらくがき帳

    岡山にはオープンセミナー岡山と言う最高のイベントがあります。 okayama.open-seminar.org 昨日は id:t-wada さんや id:naoya さんの資料がホットエントリー入りしてました。 この登壇はそれと同じイベントになります。 その他の方も超豪華講師陣の中で、私が出来る精一杯の経験も踏まえたお話をさせていただきました。 speakerdeck.com この中で出て来る、データベースリファクタリングは当に素晴らしいです。 OracleベースなのですがMySQLだろうがPostgreSQLだろうが必ずためになるです。 ですが、このは既に廃刊になっており再販の予定もありません… 僕は後世に絶対必要なの一つだと思っているので再販のためにも皆さんの要望の声を上げていただけるとうれしいです。 そしたらもしかしたらが世に復活するかもしれません。 またSQLアンチパタ

    データベースリファクタリングについて話をしてきた #OSO2017 - そーだいなるらくがき帳
  • データベースのスキーマ変更と開発環境のデータ管理をいい感じにする - Pepabo Tech Portal

    こんにちは。EC事業部カラーミーショップグループの小野です。今回はカラーミーショップにおける「データベーススキーマの変更方法」と「開発環境データベースの管理方法」について紹介します。 アプリケーションの構成 カラーミーショップは複数のアプリケーションが1つのデータベースを共有して動作しています。使用言語はPHPRubyです。PHPで書かれたアプリケーションはサービス開始当初から動き続けており特にWebアプリケーションフレームワークは使用していません。Rubyで書かれたアプリケーションはそれに比べると最近作られたものでRuby on Railsを使用しています。 この記事の問題領域 データベースのスキーマ情報はアプリケーションの進化とともに変わっていきます。アプリケーションのコードがgitなどのバージョン管理システムで管理されているように、データベースのスキーマ変更や最新のスキーマ情報もバ

    データベースのスキーマ変更と開発環境のデータ管理をいい感じにする - Pepabo Tech Portal
  • #ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ

    名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる!! 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる

    #ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
  • SQLアンチパターン 幻の第26章「とりあえず削除フラグ」

    SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902Read less

    SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
  • DELETE_FLAG を付ける前に確認したいこと。 - Qiita

    DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか?」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計

    DELETE_FLAG を付ける前に確認したいこと。 - Qiita
  • 開発者のためのSQLパフォーマンスの全て

    前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検

    開発者のためのSQLパフォーマンスの全て
  • DBスキーマもバージョン管理したい!

    PostgreSQLカンファレンス2013 LightningTalk (2013-11-13: migr8.rbの設定箇所を若干修正) (2013-11-14: SQLite3での設定等を修正、「migr8.rb new --table=users」を追加)

    DBスキーマもバージョン管理したい!
  • Devsの常識、DBAは非常識

    1. MySQL Admin が見た Devs の常識、 DBA は非常識 2013/09/14 yoku0825@MyNA PHP Conference 2013 2. \こんにちは!/ ● yoku0825 ● とある企業の DBA ● MySQL 歴 5 年くらい ● オラクれない ● ポスグれない ● 嫁の夫 ● せがれの父 ● 日 MySQL ユーザ会 (MyNA) のスベり担当 3. \しゃべること!/ ● 日常的に MySQL のソースコードに触れる変態 DBA がフツーの Devs に投げた愛のマサカリ集 ( のつもり ) ● ウチの開発言語は PHP > Java >> Ruby らしいです ● ウチでは DBA がサーバーの構築、 Devs が設計・ テーブル構築・運営、 DBA はトラブルシュートや改 善提案 ( 運用 ) 、というサイクルで回しています。

    Devsの常識、DBAは非常識
  • ドキュメント指向のNoSQLデータベース(CouchDB、MongoDB)編

    書籍紹介 連載は下記書籍から第5章を基に、@IT向けに再構成して掲載しています。 目次 序 章 ビッグデータの時代 第1章 NOSQLとは何か? 第2章 NOSQLのデータモデル 第3章 アーキテクチャの基概念と技術 第4章 HadoopはNOSQL? 第5章 主なNOSQLデータベース製品 第6章 NOSQLデータベースの選択基準 第7章 NOSQLを使うビジネス 連載は書籍『NOSQLの基礎知識』(リックテレコム刊、ISBN:978-4897978871)で解説されている内容から一部を抜粋し、連載向けに一部再編集して掲載したものです。 書籍では、一般にNoSQLと呼ばれている各種データベース技術について、基概念から主要なプロダクトの特性、ベンチマーク結果までを紹介しています。データモデルやアーキテクチャの違いといった基概念から、各プロダクトの特徴を理解できる内容になっていま

    ドキュメント指向のNoSQLデータベース(CouchDB、MongoDB)編
  • ありがちなデータベース設計を共有することができる『DB Patterns』 | 100SHIKI

    これまたマニアックな苦笑。 DB Patternsでは、ありがちなデータベース設計を共有することができる。 フォトアルバムだったらこういうテーブルがあって、こことこのキーが共有されるとかなんとかをグラフィカルに見ることができる。 まだ投稿も少ないし、いろいろ突っ込みどころもあるのだが、初心者のうちは確かに悩むところだし、便利なサービスではなかろうか。 ユーザー登録をするとすでにあるパターンをForkしたり、新しく作ったりもできるようだ。興味がある方はどうですかね。

    ありがちなデータベース設計を共有することができる『DB Patterns』 | 100SHIKI
  • 1