データベースに画像を保存するのはありでしょうか？MySQL（マイエスキューエル）は、TCX DataKonsultAB社などが開発するRDBMS（リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。
RDBとNoSQLにみるDB近現代史 データベースに破壊的イノベーションは二度起きるか？ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
「ユーザー目線」のシステムを目指して RDBが従来の階層型DBに比べて優れていた点はいくつか挙げることができますが、シェアを伸ばすうえで最も大きな影響は、ユーザーが使いやすいデータ構造とインタフェースにこだわったことです。すなわち、「テーブル」と「SQL」の発明です。 RDBでは、すべてのデータを「テーブル」というただ一つのデータ形式によって表現します。テーブルは、見た目が「二次元表」に似ているため*3、Microsoft ExcelやGoogle ドキュメントなどのスプレッドシートを使い慣れた人が見ると、データを格納する方法が直観的にイメージしやすいという利点があります。実際、こうした二次元表によるデータ管理は、Excelなどのソフトウェアが登場する前から一般的な方法だったため、RDBが登場した当時の人々にとっても受け入れやすいものでした。 テーブルが画期的だった点は、もう一つあります。
SQLite4の開発物語
SQLiteの歴史 2000年 リリース1 HashベースのGDBMストレージエンジン SQLite1はGPLのGDBM(GNU Database Manager)エンジンを使ったので、その流れからライセンスはGPLで始まります(現在はパブリックドメイン)。この時からServerlessとSinglefile databaseがSQLiteの基本方針です。しかし、元となったGDBMはHashテーブルでありレンジスキャンができないので、Berkeley DBのドキュメントを2日ほど読んでからB-Treeストレージエンジンの開発を始めました。 2001年 リリース2 B-Treeストレージエンジン SQLiteが携帯電話や自動車、冷蔵庫などに搭載され広がり始めたのです。今はもうなくなりましたが携帯大手のモトローラから「バイナリーデータをサポートしてほしい」と言われてSQLite3の開発が始まり
ファイルシステムよりも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
Citus 12.1 is out! Now with PG16 Support. Read all about it in Naisila’s 12.1 blog post. 💥 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 appropri
ER図レビューの３つのポイント - 設計者の発言
前回記事で、業務システム開発の上流工程でDB設計がないがしろにされるケースがあると指摘したが、よほど低レベルな職場でない限り、今では上流工程でのER図の作成が標準化されるようになっている。 ところが、そのER図がまるでショボいにも関わらずレビューで承認されるケースがあとを絶たない。理由は単純で、ER図があるかどうかだけがチェックされて、内容レベルの検証がなされていないためだ。それはとりもなおさず、DB設計を的確にレビューできる技術者がいないためでもある。 ER図を見れば、プロジェクトが成功するかどうかまではわからないかもしれないが、「デスマーチ化するかどうか」はわかる。それほど便利な図面が提出されながらレビュワーのスキルが足りないのでは、設計標準の持ち腐れというものだ。 そこで、ER図を効果的にレビューするためのポイントを紹介したい。構成的な心地よさがあるか、キー構成が単純すぎないか、創意
T字系ER手法で僕がしていた論理削除（via とりあえず削除フラグ） - ozamasa’s blog
@t_wadaさんのこのスライド SQLアンチパターン 幻の第26章「とりあえず削除フラグ」 from Takuto Wada www.slideshare.net パラパラと眺めていたら「T字系ER手法」ってのが出てきて、久しぶりにいろいろ思い出してしまったので、ちょっと書こうかなと思います。 T字系ER手法は西暦2000年あたりにSIerの一部で流行っていたデータベース設計手法で、原則（なのか？）についてはこのエントリーに書いてもらってあるとおりです。 mike-neck.hatenadiary.com 抜き出すと、 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意味のあるデータだけのエンティティだけですべての業務のデータを構成できる 日付を持つデータはイベント(これもひとつのエンティティ) NULLのデータは絶対に持ってはならない テーブルはでかく作るな、小さ
論理削除が云々について - mike-neckのブログ
今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基本的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://engineering.mercari.com/entry/2017/12/18/deadlock
rdb antipattern refactoring
MySQLアンチパターン
RDBアンチパターン // Speaker Deck
Time-series-database-world
https://qiita.com/kantomi/items/07a691e19725e3cd3c4d
ハンドノート T字形ERモデル セミナー資料 (Author; S.Toriyabe SYSTEMS DESIGN Co.,Ltd. Japan)
