他システムとのデータベース連携について - Qiita
システムエンジニア Advent Calendar 2015 - Qiita 20日目の記事です。 システム開発をしていると、他システムのマスタやトランザクションデータが必要となる場合がよくありますね。 システム間のデータ連携としては、 リソース共有（データベース共有、ディスク共有） アプリケーション連携（RPC、Web API、MOM1） ファイル連携(CSV連携、etc) などの方法がありますが、ここではデータベース共有を実現するためのデータベース連携方式について考えてみたいと思います。 データベース連携方式について 既存システムがレガシーであったり、違うベンダーが構築したサーバーであるなどの理由で、新機能や拡張機能を別のサーバー上で新システムとして構築する場合があります。もちろん、データベースも新たに用意する場合が多いのですが、その場合は既存システムには極力修正をいれない方針でデータ
論理削除 Casual Talks #1 で「論理削除しない」という話をしました - moroのブログ
互いの前職での先輩後輩である @kenchan と企画した論理削除 Casual Talks #1で、「論理削除しない」という話をしてきました。 話す内容が各話者で面白いほどかぶっていたのでなかなか大変でしたが、普段から言っている「論理削除するな」「削除じゃないからちゃんと機能を設計しましょう」という内容を話してきました。 他の方の話も、かぶっているようで新しい視点もあって、いち参加者としてもたいへん勉強になりました。
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
Clojureの作者が作ったデータベースDatomicが凄い
プログラミング言語Clojureの作者Rich Hickey氏率いるClojure HackerのチームがDatomic(デートミックと発音するらしい)というデータベースをリリースしました。これが何やらとてつもないです。10年先を行ってる技術じゃないでしょうか。 まだ本番サービスは始まっていませんが開発環境用のライブラリが配布されています。 Datomicは斬新なアーキテクチャなので一言で説明するのはとても難しいです。 私が理解できたことを簡単に説明します。 2014/1/20追記 ライセンスモデル、サポートストレージ、サービスとしてではなく独立して使用する形になるなど記事作成時の内容から色々変更が合った部分を更新しました。 変更不可なAppend-onlyデータベース 従来のデータベースで、あるレコードを変更するというのはそのレコードに対応した場所があり、そこのデータを書き換えるというこ
Btrieve後継DB「Pervasive PSQL」の最新版、マルチコア性能を向上
エージーテックは2011年8月1日、リレーショナルデータベース管理システム（RDBMS）の新版「Pervasive PSQL v11」を販売開始した。2008年1月以来の新版投入となる。新版では、新たに並列処理などによってマルチコアCPU使用時の性能を高めた。価格は、10ユーザー時に19万8000円（税別）、1ユーザー時に1万円（税別）など。開発会社は、米Pervasive Software。 Pervasive PSQLは、Windows（x86）およびLinux（x86）上で稼働するリレーショナルデータベースである。組み込み用途に向く。1990年代前半によく使われていた米NovellのネットワークOS「NetWare」が標準装備していたデータベース「Btrieve」を源流とする。ODBC経由のSQLクエリーに加え、ISAMトランザクション処理が可能なBtrieve APIを介してDBア
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベース設計徹底指南