１．はじめに RDBでの階層構造の関係を持つデータを扱う上で、 効率的なデータの持ち方や抽出方法について検証を行っています。 結論から先に 階層構造を扱う方法として下記の種類があります。 隣接リスト 経路列挙 入れ子集合 閉包テーブル 再帰クエリ（WITH RECURSIVE）を使うと階層データを扱う上でのパフォーマンスが得られます。 検索性、更新量、データ量など加味すると隣接リストで再帰クエリを用いるのがよさそう。 ２．階層構造を持つデータの概要 階層構造を持つデータとは 複数の要素（データ）が親子関係で結びついている構造を持つデータ 1つの要素が複数の要素の親になることができ、 また、1つの要素が複数の子要素を持つこともあります。 ある要素を親として、細分化された子要素であったり、 類似する要素を抽象化したものを親要素とするようなデータ。 階層構造を持つデータの例 組織における事業部、
時系列データベースであるInfluxDBのユニークな機能のひとつに、継続的にデータを処理して保存するために使用するクエリーの一種であるContinuous Queryがある。これについて説明する3部作の第1弾は、Continuous Queryの概要と簡単な例を紹介する。 合計や集約、あるいは計算したデータを返すクエリは、アプリケーション開発では頻繁に使われます。例えば、メトリクスをレポートするオンラインダッシュボードアプリケーションを開発しているなら、データを要約したものを表示する必要があるでしょう。大量のデータを処理する必要があったり、繰り返し実行するためスケールしないため、こういった要約クエリは一般的には計算コストが高くなります。そんな時、必要になったらすぐに取り出せるように要約済みのクエリの実行結果を事前に計算して保存しておければ、データベースに負荷をかけずにダッシュボードアプリケ
[[http]] # Name of the HTTP server, used for display purposes only. name = "example-http" # TCP address to bind to, for HTTP server. bind-addr = "127.0.0.1:9096" # Enable HTTPS requests. ssl-combined-pem = "/etc/ssl/influxdb-relay.pem" # Array of InfluxDB instances to use as backends for Relay. output = [ # name: name of the backend, used for display purposes only. # location: full URL of the /wri
InfluxDBのクラスタリング、高可用、マネタイズについての変更(InfluxData Blogより) オープンソースのソフトウェアにとってどのようにマネタイズを行うかはとても重要な問題です。InfluxDBプロジェクトにおいては、オープンソースのユーザーへの貢献とマネタイズの両立を検討した結果、高可用およびクラスタリングの機能をクローズドソースで提供していくことになりました。本決断に関わるInfluxData社のブログ記事を紹介します。 出典について この記事はInfluxData BlogのPaul Dix氏によるUpdate on InfluxDB Clustering, High-Availability and Monetization(2016/3/10)を翻訳したものです。 「InfluxData社はどのようにお金を稼ぐのか？」これはInfluxDBのプロジェクトを発展させ
当ブログでは、これまでに『Amazon Redshiftに対応している事・繋がる事』を1つの評価軸として幾つかのツールを紹介して来ましたが、その一覧に新たに加えても良さそうなツールの情報を先程目にしましたので、当エントリでその内容についてご紹介してみたいと思います。それがこちらの『DBeaver』です。 DBeaver | Free Universal SQL Client これまで紹介してきたDB関連ツール 参考までに、これまでに紹介して来たDB関連ツールの一覧を以下に纏めます。 Intellij IDEA(Ultimate Edition) Amazon RedshiftのMac OS X向けGUIツールとして『Intellij IDEA Ultimate Edition』のDatabase Toolsを使う ｜ Developers.IO 0xDBE → DataGrip Mac/W
Oracleというかテーブル設計の話。 マスタテーブルを作る時に、時間によって値が更新されるマスタデータがある。 そういった場合にどうテーブルを設計しているか、今までの見たことあるパターンを考えてみた。 1.現在値のみ保持 何も考えなければこれになる。 値が変わった場合は参照している過去データも新しい値になってしまう。 つまり、履歴管理できない。 なので、「過去データについては当時のマスタ情報で利用したい」という要望に応えられない。 どうしてもという場合は、既存のデータを残したまま別のレコードを追加し、 そちらで新しい値を入れてそっちを使ってもらう。 同じマスタが別のデータとして存在してしまい、ユーザーがどっちかを選ぶとか片方を削除するとか、 テーブル構造がシンプルだけど運用が複雑になってしまうという非常にマズイパターン。 2.現在値＋過去の履歴データのテーブル このパターンは1.のテーブ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「達人に学ぶDB設計」、「SQLアンチパターン」を読んだのでDB設計をする流れとその過程でのチェックポイントをまとめてみました。 今回は本に載っているものの中でも特に重要そうな部分に絞ってみました。 さらに詳しいことを知りたい方は本を購入してみてください。個人的には達人に学ぶDB設計徹底指南書のほうがおすすめです。こちらだけあれば十分だと思います。 DB設計には大きく分けて論理設計と物理設計の二つがありますが、今回はアプリケーション開発でメインとなる論理設計の部分に焦点をあてて説明をします。 一番最後にチェックポイントだけをま
MySQL（マイエスキューエル）は、TCX DataKonsultAB社などが開発するRDBMS（リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。 PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。
リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。
Knex.js (pronounced /kəˈnɛks/) is a "batteries included" SQL query builder for PostgreSQL, CockroachDB, MSSQL, MySQL, MariaDB, SQLite3, Better-SQLite3, Oracle, and Amazon Redshift designed to be flexible, portable, and fun to use. It features both traditional node style callbacks as well as a promise interface for cleaner async flow control, a stream interface, full-featured query and schema build
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
本連載では、サーバーサイドJavaを使って業務アプリケーション開発を行う熱血若手エンジニアのために、面倒な作業が楽になる便利なツールをご紹介します。「定時になったらスマートに帰社してアフター5を存分に楽しみたい！」や「設計書やレビューの準備に煩わされるのは嫌だ、コーディングに集中したい！」などを実現してくれる便利なツールやソフトウエアを、サンプルコードを交えて説明します。 はじめに サーバーサイドJavaによるWebシステムでは、クライアントから受け取ったデータをもとに、データベース上のデータを参照したり、更新したりすることがよくあります。 本当は、クラス設計などに時間をたっぷり費やして、効率がよく品質の高いプログラムを書きたいのに、データベースに登録されたたくさんのテーブル／カラムから必要な値をResultSetで受け取り、それをJavaの一つ一つオブジェクトに格納して……など単調な作業
ナチュラルキーとサロゲートキーについての議論
とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。 リレーショナルモデルにあるのはナチュラルキーだけリレーショナルモデルには「サロゲートキー（代理キー）」という概念はない。まずこの点に注意して頂きたい。サロゲートキーとは、データベースアプリケーション開発において実用上必要とされる機能であって、本質的には不要のものである。リレーショナルモデルでは、いわゆるナチュラルキーというものがあれば機能的には十分だからだ。 そのためにはまず「キー」という概念が何を指し示すかということについて正しく理解しなければならない。リレーショナルモデルではキーと呼ばれるものは候補キーとスーパーキーという2つの概念だけである。「タプル（≒行）の値を一意に決定することができる属性（≒カラム）の集合」の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
