Embarcadero Developer Camp

Size: px

Start display at page:

Download "Embarcadero Developer Camp"

ひさともたもん
4 years ago
Views:

1 17 Th Developer Camp T2 データベースアプリケーション開発アプリケーション開発者のための DB べからず集からパフォーマンスチューニングまで株式会社ドリームハイブ代表取締役山本悟株式会社日本情報システム筑木真志アナハイムテクノロジー株式会社代表取締役はやしつとむ 1

2 自己紹介名前 : 山本悟 ( やまもとさとる ) 代表取締役 & 不動産投資専門 IT コンサルタント会社 : 株式会社ドリームハイブ会社 URL : お得なコンテンツ配信サイト : 山本のブログ : 略歴 : 17 歳からこの IT 業界へ Delphi は 1.0 からの親友経営に加えシステム開発と IT コンサルティングスピーカーなどが主な仕事ですがテレビ埼玉に出たりしたこともあります 2

3 自己紹介名前 : 筑木真志 ( ちくぎしんじ ) 多分同姓同名はいません会社 : 株式会社日本情報システム URL : nis@nihon-jyoho.com 会社概要 : 土木建築測量系の開発が多い GIS とか DB を活用したシステムなんて大好きですでも会計とか集計処理など OS や言語問わずいろいろやっています GIS 関連スクールの講師とかもやることがありますあとレガシーシステムのお守りとか移行サポートとかぶっちゃけ IT 系の大工さんというか何でも屋さんだから道具にこだわる故に自分は C++Builder が大好き!! 3

4 自己紹介名前 : はやしつとむ ( 林務 ) 代表取締役 & Firebird 日本ユーザー会理事会社 : アナハイムテクノロジー株式会社 URL : メール :tsutomu.hayashi@anaheim-tech.com Twitter :tomneko_p 略歴 : 建設不動産の会社株式会社アペックスの専務も兼務 2003 年に Firebird 日本ユーザー会を立ち上げた張本人各地の OSC 等で盛り上げ役をやってます名前は漢字でググると全く出てこないのでひらがな表記です ( 笑 4

5 17 Th Developer Camp 1 移行でのケースその 1 5

6 古い Delphi から新しい Delphi にマイグレーション導入先のハードウェアのリプレースに伴い OS のバージョンが変わったシステムを利用するユーザー数が増加したとりあえず今の構成のまま単純にマイグレーション BDE のエラーが出た? 複数人で使おうとしたらエラーが出た? 6

7 いきなり新しい Delphi に移行しようとしてません? 移行はステップバイステップで! 様々な要因でステップが変わります OS のバージョン Delphi のバージョン文字コードの種類データベースのフレームワーク基本は Delphi 2007 への移行を挟むこと複数の動作環境を準備しておきましょう! いきなり移行するのはやめよう! 多くの場合で工数が増えます 7

8 移行の基準 OS のバージョン 98 ~XP 2000~XP 2000~ (Vista 対応 ) Delphi のバージョン ~Delphi 6 Delphi 7 ~Delphi 2006 Delphi 2007 Delphi 2009~ 7 対応は 2010 から文字コード ANSI UNICODE データベースのフレームワーク BDE DBX DBX 98 が必須 Vista 以降の OS +ANSI Vista 以降の OS +UNICODE 8

9 開発環境はどうするのが良い? 仮想環境を構築するのがオススメ仮想化 :1 台のコンピュータをあたかも複数台のコンピュータであるかのように論理的に分割しそれぞれに別のOSを動作させることで複数の環境を少ないリソースで比較的安全に構築することができる Hyper-V : マイクロソフト VMWare : ヴイエムウェア Xen : シトリックスシステムズジャパン VirtulBox :Oracleなど複数の環境 = 複数の PC 複数の環境を 1 台の PC で 9

10 BDE をそのまま使おうとしていませんか? BDE はもうダメ! いやマジでマジで Delphi 7 附属の BDE5.2 で開発およびメンテナンスが終了してるので正規サポートは望めない XE に付属している BDE も Delphi 7 Professional レベルのものであり Enterprise エディションの SQLLink は含まれていない ) あくまでも過去の資産 (dbase/paradox,odbc 接続 ) の保守用せめて 3rd パーティの互換コンポーネントを利用しましょう BDE を残すのはやめよう何かあったら開発者の責任! 10

11 BDE アプリは互換コンポーネントで置き換える BL: ビジネスロジック UI: ユーザーインターフェイス PC デスクトップアプリケーション BL UI TTable/TQuery など DB PC デスクトップアプリケーション BL UI TXXTable/TXXQuery など DB 移行はとても簡単だけど基本的にはユーザーが単数の時だけにしましょう 11

12 17 Th Developer Camp 2 移行でのケースその 2 12

13 古い Delphi から Web に対応するより広いネットワーク対応を求められたディスクトップからイントラネットイントラネットからインターネット Professional 版でリモート接続って OK? パフォーマンスが超低下 13

14 コネクション数を考えてます? ローカル or リモートそもそも Pro 版はリモート接続できないのでライセンス違反ですコネクション数が増えればパフォーマンスが悪くなりがちです整合性が取りづらくなるはずです Access とかのクラサバだと最悪です自分でどうにかするより Enterprise 版買う方が速くて楽で安くて安心ですコネクション数を考えないのは止めよう! 規模が大きくなるにつれ問題の切り分けがしづらくなります 14

15 17 Th Developer Camp 3 移行でのケースその 3 15

16 古い Delphi から多層アプリケーション化業務拡大によりクライアントを増加単純にクライアントアプリケーションを配布パフォーマンス的にどうなの? 低減するはずの工数が何故か増加 16

17 多層化がイントラ / インターネット対応のカギ単層 P C デスクトップアプリケーション BL UI TTable/TQuery など DB DB サーバ二層 P C デスクトップアプリケーション BL UI TXXTable/TXXQuery など DB 多層 P C デスクアプリ UI BL TSQLTable/TSQLQuery/ TclientDataSet など DataSnap サーバなど DB DB サーバモバイルや Web モバイルアプリ UI BL: ビジネスロジック UI: ユーザーインターフェイス 17

18 単層のみで作っちゃってないですか? クライアントの台数は? クライアント 1 台だけにしか対応しないいわゆるデスクトップアプリケーションのときのみ単層構造でも良いでしょうでも dbexpress(dbx) を使って多層構造に対応しておきましょう DataSnap などを使えば後の拡張が容易です単層構造のアプリで居続けるのはやめよう! 後がもっと大変になります 18

19 17 Th Developer Camp 4 新規開発でのケースその 1 19

20 リッチすぎた UI 顧客からの要求帳票のヘッダーと明細は同一画面で表示 / 編集 Access のように項目番号と項目名を一緒に表示項目番号が判れば項目番号を直接入力したい項目名の内容を直接入力して絞り込みもしたい Excel のように表形式で編集編集中の数値はリアルタイムに集計集計値のチェックをしながら入力したいアプリケーションのパフォーマンスが超悪い ( その正体は次のページで ) 20

21 結局こんなことをやってしまいました帳票ヘッダ帳票明細 (TDBGrid) 集計結果大量のデータベースコンポーネント 21

22 データベースコンポーネントの貼りすぎレコードの取得 (SELECT) と更新 (UPDATE/INSERT) が別のデータベースコンポーネント違うフォームでも同じテーブルを参照するデータベースコンポーネントを貼っているテーブルの仕様が変わった場合は? データベースコンポーネントはデータモジュールに分離して一元的に管理しよう! 22

23 データコントロールコンポーネントの貼りすぎ一つのフォームにそれだけの情報が必要なの? ステータスコードなどの各種マスターの参照に TJvDBLookupComboEdit を使用している常にクエリが発生するヘッダと明細はフォームを分けるなどひとつのフォーム上に必要な情報は何かを見極めよう! 23

24 データの絞り込み明細情報を TADOTable で参照し必要なレコードを Filter プロパティで絞り込んでいるテーブルコンポーネントは全てのレコードをフェッチする Query コンポーネントを使用して取得するデータをまず限定! 24

25 17 Th Developer Camp 5 新規開発でのケースその 2 25

26 そんなデータベースで大丈夫か? 大丈夫だ問題ないということでお手軽で使いやすい Access を選択統計データを処理 ( データベース的な意味で ) たった数万レコード CPU パワーは問題ないのにフェッチ & 集計で数時間 26

27 データベースの選択はさ本当にそのデータベースでよかったの? リモート接続する? しない? データベースの規模を把握して規模にあったデータベースを選ぼう! データベースの設計も大事! 27

28 17 Th Developer Camp 6 DB 設計基本のキ主キー 28

29 主キーの無いテーブルなんての無いコーヒーのような商用の業務系システムでもデータベースに主キーがないケースが見受けられる主キーがないテーブルなんてあり得ない! 29

30 主キーに使うデータ型 smallint の主キーで一ヶ月で止まったシステムがあった ( 僕じゃないよ ) 現状では 64bit 整数などを使う Bigint int64 クラスタ化するときは必要なカラムの複合インデックスなどで構成すべき主キーを SMALLINT にしない 30

31 主キーをクラスタ化する? Oracle MS SQL DB2 Sybase MySQL PostgreSQL ではクラスタ化インデックスを作成出来るクラスタ化するとそのインデックスでのアクセスは高速化されるけど他のインデックスでのアクセスは遅くなるテーブルの更新も遅くなる可能性があるなんでもクラスタ化しない 31

32 主キーをコードに使ってる? 主キーは一意であればいいので seaquence などを利用コードは人間が見て分かる意味のある数字や文字にするインデックスのサイズを小さくするとインデックススキャンが速くなるので文字型の主キーはやめよう主キーをコードに流用するのはやめよう 32

33 17 Th Developer Camp 7 DB 設計基本のホインデックス 33

34 インデックス有りますか? RDBMS はインデックスの固まりなんか遅いと思ったらインデックスが無い / 使われていないことがほとんど DB で一番遅いのはディスク I/O なのでこれを減らすためにインデックスを使うインデックスがない DB なんて意味がない 34

35 その SQL PLAN 確認しました? PLAN= 実行計画どのテーブルにどうアクセスしてデータを取るか表示される PLAN は各 DB のバージョンによっても変わる考えてるのはオプティマイザルールベース / コストベースがありヒントも指定出来る PLAN を確認しないで SQL を発行しない 35

36 そのインデックス使われてますか? テーブルの特定のカラムを検索条件にしてそのカラムにインデックスがあっても使われないことがある SELECT * FROM TBL WHERE SEQ_NO=10 というような単純なクエリーでも選択ミスが起きる可能性ヒントを与えてインデックスの使用を促すことも必要インデックスを作成すれば速くなるわけではない 36

37 テーブルコンポーネント使ってませんか? ちゃんとクエリーを書いて検索条件を指定してデータセットを小さくしよう適切にインデックスを張って使用して小さいデータセットを使う事 Delphi 的にテーブルコンポーネントだと丸ごとアクセスなので RDBMS の意味がない 37

38 データベースのメンテしてますか? InterBase/Firebird,PostgreSQL 等のバージョニングデータベースではテーブルデータの定期的なメンテナンスをしないとインデックススキャンでも無駄が発生します InterBase/Firebird では Sweep やバックアップ + リストア PostgreSQL では Vacuum を定期的に実行しましょうバージョニングを採用した DB では定期メンテしないと遅くなるかも 38

39 17 Th Developer Camp 8 DB 設計基本のンジョイン 39

40 テーブルのジョインは出来るだけ結果セットを絞る基本的にクロスジョインしない SELECT T1.A, T2.B FROM T1, T2 とかすると 1000 行と 1000 行でも百万行になるクロスジョインはやめよう 40

41 OUTER JOIN では NULL が発生する? LEFT/RIGHT の OUTER JOIN では結合先のテーブルにない値が NULL になる主キーを SELECT するようなケースでも NULL になることがあるので注意 OUTER JOIN 後には NULL が無いと思い込まない 41

42 そのカラム外部キー設定されてる? インデックスがあればジョインは速くなる可能性がある外部キーがあるとテストしずらい場合もあるのでその場合は二次インデックスでもよいジョインで使用するカラムにインデックスが無い! 42

43 暗黙の型変換信用してる? ジョインするキーで文字型と数値型の比較はしないと思うがそういうケースもある明示的にキャストして暗黙の型変換を信用しないこと暗黙の型変換を信用しないこと 43

44 沢山のテーブルをジョインするとわけがわからない? その為にビューを使ったりもするがビューではインデックスが使われないケースがあるマテリアライズドビューを使ったりするとこんどはディスクとメモリを食う手続き型で記述できるストアドの利用も検討した方がよい SELECT 文だけで解決しようと思わないこと 44

45 17 Th Developer Camp 9 データベース問題の解決 45

46 エンバカデロのデータベースツール DB 設計に関わる問題の解決には SQL パフォーマンスの問題解決にはデータベースの管理やデータ移行については ER/Studio DB Optimizer DBArtisan 確実なデータ設計を実現正規化や異なる DB へのモデルの移行なども支援 SQL パフォーマンスのボトルネックを検出し修正経験やカン頼みの作業から脱却 DBA の日々 DB 管理業務をサポート異なる DB へのデータの移行にも対応 46

47 17 Th Developer Camp べからず Know-how 集 47

48 移行でも新規開発でも DB 注意点は同じ DB のエンジンを確認するべし Microsoft Access / SQLite / InterBase / Firebird / MySQL / PostgreSQL / Oracle / Microsoft SQL Server / DB2 / Sybase..etc Accessを共有しての似非クラサバは絶対禁止条件つきだけど Express 版はとても便利アプリケーションの規模に応じたエンジンを DBへのアクセスを確認するべし BDE / dbexpress / dbgo (ADO) /ODBC / API 直叩き / 埋め込みSQL..etc 48

49 Professional 版での dbexpess についての注意 EULA の追加条項によってリモート接続はできない MySQL や InterBase のドライバは同梱されているけどローカル接続に限定される解決法その 1: 素直に Enterprise 版以上にする Oracle や MSSQL DB2 のドライバもあるよ! 解決法その 2: Professional 版では dbgo が事実上唯一の選択肢 BDE? なにそれ? 49

50 Access 便利ですよねとにかく手軽で使いやすい!(SQL ビューを除く ) VB / Delphi / C++Builder のローカル DB としても便利でも統計データを処理すると半端無いですカラム数 :200 カラム以上レコード数 : 数万行 *.accdb のサイズ :350MB(!) フェッチ & 集計で数時間かかりました ( 本当 ) CPU:C2Q Q9550 メモリ :8GB OS:Vista x64 同じデータを SQL Server Express に処理させたら 10 数分 50

51 Express 版ってなに? SQL Server と DB2 には Express 版がありますサポートがないけど無償 (!) エンジンは製品版 ( ほぼ ) と同じ当然 dbgo や dbexpress で接続できる Microsoft SQL Server 2008 Express Edition DB2 Express-C 51

52 Express 版を選択する場合の注意点使用できるリソースに制限 SQL Server 2008 Express CPU1 コアメモリ 1GB サイズ 10GB DB2 Express-C 9.7 CPU2 コアメモリ 2GB サイズ無制限サポート保守一切無し画像ファイルを扱うとすぐにリソースを使い切るあくまでも簡易版 52

53 移行での注意点移行の範囲を明確にするべし早めにリファクタリングするべし複数バージョンのテストができる環境を用意するべし時は金なり時間は金で買えやっぱ Enterprise 版でしょう 53

54 新規開発時の注意点アプリケーションの設計はしっかりと時は金なり時間は金で買えやっぱ Enterprise 版でしょうデータベースの設計も大事! 54

55 パフォーマンスを上げるにはデータベースコンポーネントはデータモジュールに分離して一元的に管理する分割して統治せよの原則データベースコンポーネントは TDataModule で一元管理フォームは TDataModule を参照する 55

56 パフォーマンスを上げるにはクエリコンポーネントを使用して取得するデータを限定取得するデータセットが小さくなるテーブルコンポーネントは全レコードを取得するクエリコンポーネントでもレコードの追加削除が可能明細データ (TADOQuery) 結果を表示明細情報 :TDBGrid SELECT * FROM MEISAI WHERE CODE = hoge が実行される 56

57 パフォーマンスを上げるにはデータコントロールコンポーネントの使用を可能な限り減らすヘッダと明細とでフォームを分けるステータスコードのようにあまり更新しないデータは OnCreate イベント内で先読みしてキャッシュするヘッダと明細を分離 57

58 17 Th Developer Camp Q & A 58

25th Developer Camp

25th Developer Camp B1 Delphi/C++Builder ild テクニカルセッション株式会社ドリームハイブ代表取締役 IT コンサルタント山本悟マルチデバイスに対応できる DB アクセス形態を作るには? 実践テクニック自己紹介会社 : 株式会社ドリームハイブ会社 URL :http://www.dreamhive.co.jp/ お得なコンテンツ配信サイト :http://dhive.jp/ 名前 : 山本悟