データベースに画像を保存するのはありでしょうか？MySQL（マイエスキューエル）は、TCX DataKonsultAB社などが開発するRDBMS（リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。
ファイルシステムよりも35％高速に | POSTD
1. 概要 SQLiteを使うと小さなBLOB（例：サムネイル画像など）を読み書きする場合、fread()やfwrite()を使って個別のファイル上に記録されたBLOBを読み書きするよりも35％も速く (*1) 読み書きができます。 さらに、10キロバイトのBLOBを扱うようなSQLiteデータベースを考えた場合、個別のファイルにそれぞれのBLOBを格納する場合に比べてディスク領域を約20％も節約可能です。 このようなパフォーマンスの差が生じる理由は、（私たちの考えでは）SQLiteデータベースの場合、open()やclose()システムコールが呼び出されるのが1回だけなのに対して、個別のファイルに格納されているBLOBを使用する場合は、open()やclose()がBLOBの数だけ呼び出されるためだと思われます。どうやらopen()とclose()を呼び出すオーバーヘッドは、データベース
t-wadaさんとのSQLアンチパターン勉強会 | FiNC Developers Blog
t-wadaさんとのSQLアンチパターン勉強会 はじめにこんにちは、技術開発部の中森です。 社内で4ヶ月に渡り、SQLアンチパターン勉強会を開催してきました。そして、最後の締めとして、SQLアンチパターン監訳者であるt-wadaさんをお迎えし、今までの勉強会で疑問として上がった点について、討論会を行いました。 今回のエントリではその討論会の内容を紹介します。 ファントムファイルについて勉強会の中で最も議論となったのは11章のファントムファイルでした。 この章で紹介されているアンチパターンは、ファイルのバイナリ情報をDBの内部に保存するのではなく、外部のファイルに置くというものです。 t-wadaさん曰く、他の場所でも最も批判の対象となる箇所です。 ここで最も大切なことは「盲目的にアンチパターンを避けない」ということです。 最近のWebアプリケーションでは画像や動画のバイナリデータは頻繁にや
RDBMSが強すぎる件 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
以前、「RDBMSを採用すると、無料で外部キー制約とかチェック制約とかトランザクションが付いてきてオトク！！！」という発言をしたことがあって、その考えは今もあまり変わっていない。 RDBMSは単なる便利な箱じゃなくて、データの整合性を守るための仕組みがたくさん備わっている。もちろん、これらの仕組みは「タダ」で使えるわけではなく、データモデリングを学んだり、データ構造を学んだりという「投資」の結果うまく使えるようになるものだけれど。 ところで問題（？）は、RDBMSは強すぎる、ということです。 たとえば、トランザクションの話。「本質的にはトランザクション整合性である必要がなく、遅延してあとから整合性が取れてればよいような処理（つまり、結果整合性でよいような処理）」というのは、意外と多い。 多くの開発の現場では、トランザクション整合性が必要とされるか結果整合性でよいのかについてあまり考えず、「
tm-versions
TM （Ｔ字形 ER手法の改良版） は、実地の使用のなかで験証を続けて、かつ、数学・ロジック （論理学）・哲学の観点から検証を続けているので、改良を施してきています。そのために、現時点での体系 （最新の体系） を知りたいという要望が多いので、本 ホームページ で、TM の最新 バージョン を記すことにしました。TM を見直した折りに、そのつど、新しい バージョン を示していきます。 ● TM3.0 （2022-07-22） → 「モデル 作成技術 TM 入門」 （技術評論社） ● TM3.0 の元資料 （2020-12-30） → TM3.0 の技術 （説明資料 ダウンロード） ● TM2.0 （2015-06-04） → TM2.0 の基本的な考えかた （説明資料 ダウンロード） → TM2.0 の技術 （説明資料 ダウンロード） ● TM1.0 （2009-01-23） 「赤本」 「い
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: 設定より規約）を強く提唱している フレームワーク であり、それによって得られる恩恵も大きい反面、かなり強めに設計の自由度を束縛されるという特徴もあります。特に
DBのCRUDでUとDは必要ないという話を聞きましたが具体的にどう実装するの？
"CRUD is Dead"なんて言われてる方もいらっしゃるようでCRUDのUとDを禁止する流れが存在するようです。 以下のようなサイトでも言われているように、CRUDのUとDを利用せずデータをログのように扱う方法は関連するデータ（特に履歴）が失われないために好感が持てました。 http://tanakakoichi9230.hatenablog.com/entry/6715376804 http://qiita.com/Jxck_/items/156d0a231c6968f2a474 http://mike-neck.hatenadiary.com/entry/2015/03/24/231422 現在MySQLを利用してウェブサービスを作成しようと考えているのですが、実際にUとDを利用しないDB設計をするにはどうすれば良いのかというところでつまづいてしまいました。 自分で考えたものは5つ
Five ways to paginate in Postgres, from the basic to the exotic
Five ways to paginate in Postgres, from the basic to the exotic Written by Joe Nelson March 30, 2016 It may surprise you that pagination, pervasive as it is in web applications, is easy to implement inefficiently. In this article we'll examine several methods of server-side pagination and discuss their tradeoffs when implemented in PostgreSQL. This article will help you identify which technique is
flint blog: でかいテーブルの恐怖
あけましておめでとうございます。 1月も既に半ばではありますが。 昨年10月の下旬から始まった仕事のスケジュールがこれまでと較べてかなりタイトなもので、ブログの更新もすっかり滞っておりました。 今回の仕事を含め、大学時代から、何故か他人が作ったシステムの分析・改修を手掛けることが多いのですが、それらの中には動作しているのが不思議なほどに設計・実装がグダグダなものが少なくありません。 特に、データベースを利用するような比較的規模の大きなシステムにおいては、そうした出来の悪さは「手の施しようのない」悲惨な稼動状態 (加えて、にも関わらずなんとかしなければならない凄惨な作戦状況) を生み出すことに。 このエントリでは、その要因の一つである巨大な (カラム数の多い) テーブルについて述べていくことにします。 テーブル定義が肥大化する要因を個別に検討する前に、私のおおまかな判断基準を示すと、 カラム
ゲームエンジニアのためのデータベース設計
GameServerDevelopers Vol.1 https://gsdevelopers.doorkeeper.jp/events/42497
変更履歴を持つテーブルの設計 - Qiita
ある日のできごと 少し前、「ブログの記事のようなものを、履歴を残しつつ編集できるようにするにはどのようなテーブル設計が良いか？」と尋ねられたことがありました. その時, まず思いついた（というか見聞きしたことがある方法）のは以下の様な2通りの方法だった. 記事テーブルにバージョン番号を持たせる方法 記事テーブルとは別に, だいたい同じ構造の履歴テーブルを持つ方法 こられの手法のメリット・デメリットについて, すこし考えていきたいと思います. その1 記事テーブルにバージョン番号を持たせる方法 概要 この方法では, 記事テーブルは一つだけ用意し, 更新される度に新しいレコードを追加していきます. 主キーはidとなるが, これはサロゲートキーで, 本当の主キーは「記事グループid + verison」の複合主キーとなっています. 記事の最終更新日時は, 最新Versionのレコードのinser
[DB設計]汎用区分マスタについて
データベース設計について質問です。 現在、Webシステムの基本設計段階で 「汎用区分マスタ」というテーブルを設計しています。 ・多言語対応するために、一つの区分値に対して 複数の言語での名称を登録する必要がある ・今回は日本語対応のみ ・現在は「マスタを更新しない、参照のみの区分」しか存在しない ・将来的にはカスタマイズでマスタメンテ画面を追加し、 区分や区分値が更新対象になる可能性がある という前提です。 開発環境は 言語：Java,JavaScript DB：SQL Server です。 過去に他の案件で使用していた同じ役割のテーブルを参考に 現在は下記のようなテーブル定義になっています。 分類コード varchar(30) PK 区分値 varchar(30) PK 言語コード varchar(3) PK 表示名 nvarchar(100) NOT NULL 表示順 smallint
婚活支援プロジェクト(1/4):構想からデータモデル設計まで #neo4j - クリエーションライン株式会社
「婚活支援プロジェクト」とは、いわゆる婚活をしている男女のプロファイルをグラフデータベース Neo4j に登録し、理想的な相手を予測するためのデータモデルや Cypher クエリーを開発してみようという企画です。これからグラフデータベース Neo4j の活用を検討 したい方のため、構想段階から進行過程、収束に至るまでのすべて経過を、順を追って連載で詳しく紹介していきます。 第1回目:構想からデータモデル設計まで 第2回目:データ処理と問題点 第3回目:どのように改善したらいいのか 第4回目:改善したデータモデルによるデータ処理 冒頭で唐突に「予測」という言葉を使っているのでこれについて説明します。最近私は「予測こそグラフデータベース Neo4j の本領」ではないかと考えています。Neo4jには様々なユースケースがありますがその間には一見あまり共通性はありません。詐欺の摘発、マスタデータ管理
業務ロジックをアプリに置いてはいけない - 設計者の発言
業務システムを純然たるソフトウエアとして見た場合、テーブルとアプリ、そして「業務ロジック（ビジネスルール）」の３つの定義要素の組み合わせとしてモデル化できる。この中の「業務ロジック」の配置様式は、システムの開発・保守効率に決定的な影響を与える。 業務ロジックとはどういうもので、それはどのように配置されるのだろう。たとえば「注文テーブル」に「XXX数量」があるとして、その「初期値」が1000であるとしよう。素朴ではあるが、このルールも業務ロジックの一種である。これがどのように配置されるかというと、ふつうは注文テーブルのCreate文のDefault句として組み込まれる。 「初期値」だからといって、Default句で対応できるとは限らない。実際には「YYYが'A'の場合は1000だが、YYYが'B'の場合は0を初期値とする」といった条件をともなうことがある。さらに、「YYYが'C'の場合には、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://engineering.mercari.com/entry/2017/12/18/deadlock
rdb antipattern refactoring
MySQLアンチパターン
雑なMySQLパフォーマンスチューニング
Post by @dekasasaki
PostgreSQLアンチパターン
