ウノウラボ Unoh Labs: ブラウザでER図が描ける「WWW SQL Designer」紹介
miyakeです。皆さんドキュメントはしっかり書いていますか？ 近頃のWeb界隈では、詳細仕様書的なものは作らずにスピーディーに開発を進めるケースも多いかも知れません。ドキュメント作成のコストは小さくありませんし、内容を最新に保つのも一苦労です。とは言え、複数の人間が関わるプロジェクトにはER図はあると嬉しいなと個人的には思います。 今日はそんなER図をブラウザ上で作成するアプリケーション「WWW SQL Designer」をご紹介します。 以下のスクリーンショットは、このアプリを実際に触って試せるlive DEMOのものです。 WWW SQL Designer posted by (C)フォト蔵 上部のメニューからテーブルやカラムを作ったり消したりして、テーブルをドラッグアンドドロップで配置、リレーションを同じくドラッグアンドドロップで設定、というのがおおまかな作業の流れになります。まず
Programming tutorials and source code examples
AI Powered Tutorials Java Language Basics Maven Gradle JavaFX jUnit jsoup JPA Spring Java Selenium Hibernate Javascript Javascript Language HTML5 Canvas jQuery Events React Node.js Web CSS Selectors CSS Layout SVG Typescript Typescript Language Python Python Languages Python Selenium NumPy Pandas MatplotLib C / C++ C++ Language C++ STL C Language C Headers C# C# Languages C# LINQ C# Selenium Go La
iBATISを使ったO/RマッピングによるDBアクセスの実例 2：CodeZine
はじめに iBATISはSQLを利用することに注力したフレームワークです。高機能なO/Rマッピングフレームワークに比べて簡単に理解でき、レガシーなJDBC、ResultSetを使ったプログラミングから簡単に乗り換えられます。 特にSQLを多用する人には使いやすいフレームワークです。 この記事は前回の「iBATISを使ったO/RマッピングによるDBアクセスの実例」の続編です。前回はSELECT、INSERT、UPDATE、DELETEの基本的な記述方法についてサンプルを紹介しました。今回はSELECT文に注目し、検索結果のマッピングと動的SQLの記述方法について説明します。 iBATISの基本的な内容は、前回の記事を参考にしていただけると、分かりやすいと思います。対象読者Javaの基本をマスターしている人SQL文を理解している人 必要な環境 iBATIS 2.3.0、J2SE 5.0の環境を
PostgreSQL パフォーマンスチューニングまとめ - 徒然なるままにBlog
PostgreSQLをチューニングする機会があったので その時に調べたチューニング項目を備忘録として残しておきます。 バージョンの違いやサーバの規模などによっても 効果は変わってくると思うのであくまで参考程度のものですが。 ・shared_buffers 7系では8000〜10000程度まで引き上げる 8系では150000程度まで引き上げることが可能、100000程度が性能のピーク これに多く割り当てるよりOSのバッファ領域として使う方が性能が向上する テーブルサイズを割り出して設定するのがベスト 簡単に設定するなら搭載メモリ量の1/4、搭載メモリが多ければ1/2ぐらいでも可 ・max_connections 7系では256程度、8系では1000程度が性能のピーク ・work_mem(sort_mem) 適切なサイズに調整する、2048〜4096程度 プロセス毎
MySQLノウハウ
いろいろな本からメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),
データベース操作ツールiSQL-Viewer、4年振りに一新して登場 | エンタープライズ | マイコミジャーナル
iSQL-Viewer project membersは3日(米国時間)、iSQL-Viewerの最新版となるiSQL-Viewer 3.0.0を公開した。iSQL-ViewerはJavaで開発されたJDBC 2/3互換のデータベースフロントエンドアプリケーション。Mozilla Public License version 1.1のもとオープンソースソフトウェアとして公開されている。 iSQL-ViewerがサポートしているデータベースプラットフォームはPostgreSQL、MySQL、Oracle、Informixなど。操作はひとつのUIに統合されており、対象のデータベース如何にかかわらず、同じインタフェースを経由して同じ操作を実施できる。 iSQL-Viewerの主な機能は次のとおり。 データベースの内容閲覧 データベーススキーマの閲覧 SQL命令を保持するためのSQLブックマーク
高パフォーマンスなストアドプロシージャの設計：CodeZine
前回はHadoopを1台のマシンにインストールし、簡単なサンプルプログラムを実行しました。また、HDFSやMapReduceについても解説しました。今回は複数のマシンへのインストールを行います。その後、大規模なデータを実際に処理し、その性能を測ってみたいと思います。
SQLで集合演算：CodeZine
はじめに SQLが集合論に立脚する言語であるということは、この連載で一貫して強調してきたテーマの一つです。その特性のゆえに、SQLは「集合指向言語」と呼ばれていますし、実際、集合的な観点から見たときに初めて、その強力さが理解できると私は考えています。しかし現実には、SQLのこの側面は長らく無視されてきました。 その背景には、SQLにも責任の一端があります。というのも、SQLはちょっと前まで、高校で習う程度の基本的な集合演算子すら持っていなかったからです。和（UNION）こそSQL-86からの古参ですが、交差（INTERSECT）と差（EXCEPT）が標準に入ったのはSQL-92ですし、除算（DIVIDE BY）が未だに標準化されていないことは、前にも述べました。だから、SQLが言語として不完全だという批判は、理由のないものではなかったのです。 しかし、現在では標準SQLに基本的な集合演算子
外部結合の使い方：CodeZine
はじめに SQLに対するよくある誤解の1つに、「SQLは帳票作成のための言語だ」というものがあります。確かに、SQLは定型・非定型を問わず、さまざまな帳票や統計表を作成するシステムで利用されています。そのこと自体に問題はありませんが、エンジニアにとってもSQLにとっても不幸なことは、SQLの本来の用途ではない結果のフォーマット整形までがSQLに求められることです。あくまでSQLはデータ検索を目的に作られた言語だからです。 しかし同時に、SQLは多くの人が考えているよりずっと強力な言語です。特に近年は、そうした用途にも対応すべく、OLAP関数をはじめとするレポート作成のための機能が多く取り入られるようになりました。システム全体としてソースを簡略化でき、十分なパフォーマンスを得られるなら、SQLの力を利用する価値は十分にあります。 本稿では、外部結合（OUTER JOIN）を利用したフォーマッ
相関サブクエリで行と行を比較する：CodeZine
はじめに SQLでは、同じ行内の列同士を比較することは簡単にできます。普通にWHERE句に「col_1 = col_2」のように書けばよいだけですから。一方、異なる行の間で列同士を比較することは、それほど簡単ではありません。ですがそれは、SQLで行間比較ができないということではありません。手続き型言語とはかなり異なる発想に基づいていますが、SQLでもそうした処理を記述することが可能です。 SQLで行間比較をする際に威力を発揮するのが相関サブクエリ、特に自己結合と組み合わせた「自己相関サブクエリ」です。本稿では、この技術を使った行間比較の応用方法を、具体例を通して解説します。稼働環境OracleSQL ServerDB2PostgreSQLMySQL（バージョン4.1以上） 対象読者 相関サブクエリの基本的な使い方を知っている方。CASE式、自己結合、スカラ・サブクエリについての知識があると
suVeneのあれ: 俺的コーディングルール SQL編
2007年01月19日 俺的コーディングルール SQL編 プロジェクトのコーディングルールがこうでなければいけないとか、他人に強制するわけではないが、自分自身で一貫性の無いコードを書くのは気持ち悪いので、オレオレルールを決めてたりする。大抵は デ・ファクト的なルールに沿う形で書くことが多いのだが、SQL や PL/SQL に関してはなかなかデファクトと呼べるものがないので(あるのか?)、メモ的に書きとめておく。 原則キーワード小文字オブジェクト名大文字カンマは後ろインデントは半角スペースで 2一つの SQL 文でキーワード毎にインデントしない(副問合せ除く) まず、1.2. に付いてなのだが、昔は「キーワード＝大文字」という意味不明な先入観で大文字で書いていた。ただ、それだと PL/SQL のキーワードも大文字、オブジェクト名も大文字で結局ほとんど大文字になってしまうのと、Shift 押す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OTN Japan - 404 Error
DB2逆引きWiki
webbook2
Infoseek[インフォシーク] - 楽天が運営するポータルサイト![Infoseek[インフォシーク] - 楽天が運営するポータルサイト](https://cdn-ak-scissors.b.st-hatena.com/image/square/67a82fbafb5e06f77d53cedfd9ceb7f789258213/height=288;version=1;width=512/https%3A%2F%2Fimage.infoseek.rakuten.co.jp%2Fcontent%2Ftop-ajax%2Fmobile%2Flogo.png)
Error Management in Oracle PL/SQL | PDF | Pl/Sql | Sql
https://www.casestudio.com/enu/database_design_freeware.aspx