SchemaCrawler
SchemaCrawler Free database schema discovery and comprehension tool SchemaCrawler is a free database schema discovery and comprehension tool. SchemaCrawler has a good mix of useful features for data governance. You can search for database schema objects using regular expressions, and output the schema and data in a readable text format. The output serves for database documentation, and is designed
JDBCレイヤでDBのシャーディングを行うsharding-jdbcを試してみた - たけぞう瀕死ブログ
DBのデータ量が増えてきた場合の対策の1つとしてユーザIDなどをキーにデータベースを分割するシャーディングと呼ばれる手法があります。これをJDBCのレイヤで実現してしまうsharding-jdbcというライブラリを見つけました。 github.com sharding-jdbcは中国のdangdang（当当）というEC大手企業が開発したOSSで、SQLをパースし、SQLに含まれるシャードキーを抽出して接続先のデータベースや、参照するテーブルを切り替えてくれるというものです。 使ってみる まずはpom.xmlに以下の依存関係を追加します。 <dependency> <groupId>com.dangdang</groupId> <artifactId>sharding-jdbc-core</artifactId> <version>1.4.1</version> </dependency>
JPAからフェッチサイズを変更したかった - kagamihogeの日記
JPAだけで完結するのはさすがにムリがあったのでこういうタイトルにした。が、JPAプロバイダ固有のAPIのレベルではフェッチサイズを変更する効果を確認できた。 JDBCのsetFetchSize変更時の動きをstatspackで見てみる - kagamihogeの日記ではJDBCを直接使用していたが、このエントリではJPAプロバイダ（EclipseLink, Hibernate）固有のAPIを使用して100万行取得するコードの速度を、フェッチサイズ変更無しと100の時とでどのくらい速度差が生じるかを確認する。 環境 DB CentOS-6.4-x86_64 Oracle Database Express Edition 11g Release 2 Java Java SE Development Kit 7u45 Eclipse Kepler(4.3.1) SR1 IDE for Java
【BET0809】Kasino online paling terpercaya di Indonesia.
Kasino online terpercaya di Indonesia
第5回 Spring環境におけるDBアクセス(2) 〜 Spring Data篇 | DevelopersIO
よく訓練されたアップル信者、都元です。前回は散々説明しといて「こんなの使わないッスよね(ｸｯﾁｬｸｯﾁｬ」っていう酷いオチでごめんなさいごめんなさい。えっと、今回が本命です。これが、私が日常的に使ってるデータアクセスの仕組みです。間違いねえっす。 ただし、前回の最後の注釈でも指摘した通り、便利で高水準なAPIは黒魔術的要素が強くなります。APIの水準と裏側の見通し *1はトレードオフですので、プロジェクトメンバーのスキル等も勘案しつつ、慎重な選択が必要なところかと思います。本連載の読者の皆様は基本的にSpringを学び始めて間もないと思っていますので、今まではSpringの中でもそこそこ見通しの良い（まだ魔術とは言えないような）機能を中心にご紹介してきました。一方、今回は比較的黒いです。なので今回はこのエントリを通じて、Spring Dataの高水準のデータアクセスAPIを学ぶだけではなく
Mirage 1.1.4をリリースしました - たけぞう瀕死ブログ
S2JDBCの2WaySQLが利用可能なデータベースアクセスライブラリ、Mirage 1.1.4をリリースしました。 http://amateras.sourceforge.jp/site/mirage/welcome.html 今回の新機能・修正点は以下の通りです。 NameConverterの実装としてRailsLikeNameConverterを追加しました。 PropertyExtractorの実装としてFieldPropertyExtractorを追加しました。 DefaultValueTypeのJDBC 4.0（Java6）への意図しない依存性を修正しました。 SQLファイルの末尾のセミコロンは削除して実行するようになりました。 例外体系を整理しました。 Spring Framework等でvalueTypesを簡単にカスタマイズできるよう、SqlManagerImpl#set
JDBC XAデータソース - nekop's blog
JBoss Advent Calendar 2011の14日目のエントリです。今日はJDBC XAデータソースの説明。 XAってなによ？ ツーフェーズコミット(2相コミット, 2PC)するためのインタフェースです。 XAとか2PCってどんなときに使うの？ 一つのトランザクションで2つ以上のトランザクショナルリソース(JDBC JCAリソースアダプタ=データベースとか、JMS JCAリソースアダプタとか)を扱う場合に利用します。 XAとか2PCってなんで必要なの？ 例えばデータベースが二つ、DB-AとDB-Bがあって、DB-AからDB-Bにデータを移す処理をするとします。このとき、DB-AからSELECTして削除してDB-Bにインサートする、というようなことをするわけですが、この処理が途中で落ちたら即データ消滅、データ重複などのデータ不整合という結果になってしまいます。XAを使うとこういった
Javaプログラマから見たMongoDB
はじめに PostgreSQLなどのRDBMSでは、コマンドラインのクライアントからSQL文を打ち込んでデータを操作することが一般的です。これに対し、MongoDBでは、コマンドラインのクライアント（mongoコマンド）からJavaScriptを使ってデータにアクセスすることができます。ただし、JavaScriptを使うといってもif文やfor文などを使うことはまれで、多くの場合は単純にJSON形式で記述したクエリーを関数の引数にして実行するだけになります。その際「find」「update」などの関数や「$gt」「$set」などのMongoDB独自のオペレータを用います。これは特定のプログラミング言語に特化した方法ではなく、少し抽象化された、MongoDB言語とでも呼べるものとなっています。 PHPやJavaなど、JavaScript以外で書かれたアプリケーションからMongoDBにアクセ
Mirage - SQL Centric Database Access Library - Welcome to Mirage
What's Mirage? Mirage is an easy and powerful SQL centric database access library. 2WaySQLThe main feature of Mirage is 2WaySQL. This makes plain old SQL template, and it is executable using any SQL client tools because parameters and conditions are written as SQL comment. SQL less UpdateGenerally, update processing are simpler than search processing. However, especially, large INSERT SQL brings u
Infinispan
In-Memory Distributed Database What is Infinispan? Infinispan is an open-source in-memory database that can hold nearly any type of data, from plain-text to structured objects. Retrieve your data with lightning-fast speeds with Infinispan's powerful full-text and vector search capabilities. Guarantee reliability and integrity by distributing your data across elastically scalable Infinispan cluster
Project Voldemort
Voldemort is a distributed key-value storage system Data is automatically replicated over multiple servers. Data is automatically partitioned so each server contains only a subset of the total data Server failure is handled transparently Pluggable serialization is supported to allow rich keys and values including lists and tuples with named fields, as well as to integrate with common serialization
MySQL+Java でサーバサイドプリペアードステートメントを使うべきで「ない」理由 - kazuhoのメモ置き場
useServerPrepStmtsのここの説明ではデフォルトがtrueになっているが、これは上述の通り嘘である。 (中略) そしてなぜfalseにされたかということの背景を察すると、trueにすることの弊害もありそうで、手放しでこれをtrueにすることを勧めることが少しはばかられる。 http://www.geminium.com/chiba_blog/2008/12/23/33/ 自分は Java 使ってないですが、MySQL の中の人が使うなって言ってます *1。その理由はメモリリークのような症状が出る可能性があるから。 So why are prepared statements a problem? Because users do not clean up/close unused prepared statements. Multiply the number of prep
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
そんなトランザクションマネージャで大丈夫か？
Redgate Flyway - Automate database deployments across teams and technologies - Redgate Software
https://blog.ik.am/entries/150
Gmane Loom
http://japan.internet.com/developer/20060207/26.html