　FileMaker って、、、あれかなぁ: MySQL Workbench

ラベル MySQL Workbench の投稿を表示しています。すべての投稿を表示

2015-04-14

ファイル起動時にFileMakerからMySQLに投げられるクエリ

FileMaker Pro をフロントエンド、MySQLをバックエンドにしたアプリを起動する時には、以下のようなクエリが投げられるんですね。　
（FileMaker Pro 13使用時）

SET NAMES utf8　［参考URL］

SET NAMES indicates what character set the client will use to send SQL statements to the server. Thus, SET NAMES 'cp1251' tells the server, “future incoming messages from this client are in character set cp1251.” It also specifies the character set that the server should use for sending results back to the client.

A

SET NAMES
            'charset_name'

statement is equivalent to these three statements:

SET character_set_client = charset_name;
SET character_set_results = charset_name;←A
SET character_set_connection = charset_name;

SET character_set_results = NULL　［参考URL］

If you want the server to perform no conversion of result sets or error messages, set character_set_results to NULL or binary:

SET SQL_AUTO_IS_NULL = 0　［参考URL］

If this variable is set to 1 (the default), then after a statement that successfully inserts an automatically generated AUTO_INCREMENT value, you can find that value by issuing a statement of the following form:

SELECT * FROM tbl_name WHERE auto_col IS NULL

If the statement returns a row, the value returned is the same as if you invoked the LAST_INSERT_ID() function.

つまり、INSERT直後、 AUTO_INCREMENT値は存在するにもかかわらず、IS NULL として認識されるというもろ刃の剣。

SET AUTOCOMMIT=0　 [参考URL]

The autocommit mode. If set to 1, all changes to a table take effect immediately. If set to 0, you must use COMMIT to accept a transaction or ROLLBACK to cancel it. By default, client connections begin with autocommit set to 1. If you change autocommit mode from 0 to 1, MySQL performs an automatic COMMIT of any open transaction.

set @@sql_select_limit=DEFAULT 　［参考URL］

The maximum number of rows to return from SELECT statements. The default value for a new connection is the maximum number of rows that the server allows per table, which depends on the server configuration and may be affected if the server build was configured with --with-big-tables. Typical default values are (2³²)–1 or (2⁶⁴)–1. If you have changed the limit, the default value can be restored by assigning a value of DEFAULT.
If a SELECT has a LIMIT clause, the LIMIT takes precedence over the value of sql_select_limit.
sql_select_limit does not apply to SELECT statements executed within stored routines. It also does not apply to SELECT statements that do not produce a result set to be returned to the client. These include SELECT statements in subqueries, CREATE TABLE ... SELECT, and INSERT INTO ... SELECT.　
※うちのDEFAULTは、 (2⁶⁴)–1=18446744073709551615　でした。こんなん返されても困るわ。

SET SQL_MODE='STRICT_ALL_TABLES'　［参考URL］

For transactional tables, an error occurs for invalid or missing values in a data-change statement when either STRICT_ALL_TABLES or STRICT_TRANS_TABLES is enabled. The statement is aborted and rolled back.

SELECT TABLE_NAME, TABLE_COMMENT, TABLE_TYPE, TABLE_SCHEMA FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA LIKE 'easyinv15' AND ( TABLE_TYPE='BASE TABLE' OR TABLE_TYPE='VIEW' ) AND TABLE_NAME LIKE '郵便番号'

INFORMATION_SCHEMA から、アプリで使用さているビューを含むテーブル情報を取得。

select database()

接続中のデータベース名を返す

describe `郵便番号`

当該テーブルのコラム情報を取得

SHOW KEYS FROM `easyinv15`.`郵便番号`

プライマリ等キー情報を取得、Cardinality ってここにあるのね。

SELECT TABLE NAME ～　から SHOW KEYS ～　（イタリック部）は、FileMaker ファイル内に登録されたすべてのMySQLシャドウテーブル（ビュー含む）に対して実行される（ｷﾘｯ

（土屋）

2012-07-06

MySQL Workbench の EER モデリングツールでリレーションシップ検証 3 （リレーションシップアイコンの種類と使い方）

前回、前々回の記事で、外部キーの設定と制約の定義方法について説明してきましたが、今回は EER モデリングツールのリレーションシップアイコンの種類と使い方について説明します。

EER モデリングでリレーションシップの設定を行う場合は、画面の左下に並ぶ 6 種類のアイコンを使います。

既存のテーブル列を使ってリレーションシップを設定する

大抵の場合は、先に基本的なテーブルを予め定義しておき、後でリレーションシップを設定する作業手順となるでしょう。そのような場合は、上記赤囲みの一番下のアイコンを使用します。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

青囲みの列に注目してください。ブランドテーブルの [ブランドID]、および取扱商品テーブルの [ブランドID] は共に既存の列にが使われています。

外部キー専用の列を子テーブルに新規追加し、1対1 の非依存型（non identifying）リレーションシップを設定する

子テーブルに外部キー用の列が作成されていない場合に、親テーブルと 1対1 の非依存型のリレーションシップを設定する場合は、一番上のアイコンをクリックします。

非依存型（non identifying）リレーションシップについては、こちらの記事をご覧ください。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

青囲みの列に注目してください。ブランドテーブルの [ブランドID]はそのままですが、取扱商品テーブルには、 [ブランド_ブランドID] という専用の列が新たに追加されています。

また、ブランドテーブル側、および取扱商品テーブル側の支線は枝分かれしていないため、このリレーションシップが 1対1 の関係となっていることがわかります。

非依存型リレーションシップの場合、コネクタは破線で表現されます。

外部キー専用の列を子テーブルに新規追加し、1対多の非依存型（non identifying）リレーションシップを設定する

子テーブルに外部キー用の列が作成されていない場合に、親テーブルと 1対多の非依存型リレーションシップを設定する場合は、上から二番目のアイコンをクリックします。

非依存型（non identifying）リレーションシップについては、こちらの記事をご覧ください。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

また、ブランドテーブル側の支線が枝分かれしていないのに対し、取扱商品テーブル側の支線が三つに枝分かれしているため、ブランド 1 に対し、取扱商品が多の関係になっていることがわかります。

非依存型リレーションシップの場合、コネクタは破線で表現されます。

外部キー専用の列を子テーブルに新規追加し、1対1 の依存型（identifying）リレーションシップを設定する

子テーブルに外部キー用の列が作成されていない場合に、親テーブルと 1対1 の依存型のリレーションシップを設定する場合は、上から三番目のアイコンをクリックします。

依存型（identifying）リレーションシップについては、こちらの記事をご覧ください。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

依存型リレーションシップの場合、コネクタは実線で表現されます。

外部キー専用の列を子テーブルに新規追加し、1対多の依存型（identifying）リレーションシップを設定する

子テーブルに外部キー用の列が作成されていない場合に、親テーブルと 1対多の依存型リレーションシップを設定する場合は、上から四番目のアイコンをクリックします。

依存型（identifying）リレーションシップについては、こちらの記事をご覧ください。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

依存型リレーションシップの場合、コネクタは実線で表現されます。

多対多のリレーションシップを設定する

子テーブルに外部キー用の列が作成されていない場合に、親テーブルと多対多のリレーションシップを設定する場合は、下から二番目のアイコンをクリックします。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

多対多の場合は、子テーブルの外部キーと親テーブルの主キーを結び付けると、テーブル名_has_テーブル名 という名前のテーブルが新たに作成されます。
このテーブルは、子テーブルに対する外部キーおよび親テーブルに対する外部キーをそれぞれ持っている点に注目してください。

上図の場合では、ブランド_has_取扱商品 というテーブルに、取扱商品テーブルの主キーに対する外部キー、およびブランドテーブルの主キーに対する外部キーが作成されることを示しています。

外部キーを確認すると、以下のようになっています。

○ブランドテーブルに対する外部キー

ブランドテーブルの主キー[ブランドID]に対する外部キーが作成されています。

○取扱商品テーブルに対する外部キー

取扱商品テーブルの主キー[商品ID]に対する外部キーが作成されています。

【関連リンク】
MySQL Workbench 基礎講習コース

2012-07-05

MySQL Workbench の EER モデリングツールでリレーションシップ検証 2 （外部キー制約の種類と動作）

前回の記事では、リレーションシップ構築時の idendifying （依存型）および non identifying (非依存型) の考え方と設計方法について述べましたが、今回は外部キーで設定可能な制約の種類と動作について説明します。

【外部キー制約とは】

子テーブル側の外部キーと、親テーブルの主キーの参照整合性を維持するために、子テーブル側の外部キーの動作を制限するものです。

たとえば、前回のブランドと取扱商品との関係性では、取扱商品テーブル側に不明な外部キー（[ブランドID]）が存在しないように制御したり、ブランドテーブル側から特定のブランドを削除した場合、そのブランドに関連する商品を取扱商品から自動的に連動して削除させたりといった振る舞い（制約）を設定します。

MySQL Workbench の EER モデリングでは、下図のように Foreign Key タブ上の Foreign Key Option を選択するだけで外部キー制約の設定が行えます。

【On Update と On Delete】

外部キー制約のオプションは、更新時（On Update）、削除時（On Delete）に大別されます。

これらは、親テーブル側（上図ではブランド）側の動作を示しており、親テーブル側のレコードが更新されたり（On Update）、削除されたり（On Delete）したときに、子テーブル（上図では取扱商品）の関連レコードの扱いを定義するという意味です。
そして、実際の関連レコードの扱いは、上図の赤囲みのドロップダウンリストから選択します。

【外部キー制約の種類】

ドロップダウンリストから選択可能な外部キー制約は次のとおりです。

RESTRICT/NO ACTION
子テーブルに関連レコードがあったら、親レコードの更新/削除を許可しない。

NO ACTION はステートメントおよびすべてのトリガーが起動された後に子テーブルの値がまだ有効であれば変更は許可される。
これに対し、RESTRICT は、子テーブルに関連レコードが存在する場合、変更は絶対に許可されない。
RDBMS ではこのような厳密な動作の違いがあるものもあるが、MySQL では RESTRICT と NO ACTION の挙動は同じ。

たとえば、取扱商品（子テーブル側）の登録を始めたら、ブランド名（親テーブル側）の変更をさせないようにする場合がこれに相当します。

CASCADE
親テーブルのレコードを更新/削除したら、子テーブルのレコードも更新/削除する。
厳密には、親テーブルの主キーの値を更新したら、子テーブルの外部キーの値も同じ値で更新され、親テーブルのレコードを削除したら、そのレコードに関連する子テーブルのレコードも連動して削除される。

たとえば、特定のブランド（親テーブル側）を削除したら、そのブランドを持つすべての取扱商品（子テーブル側）を削除するようにする場合がこれに相当します。

SET NULL
親テーブルのレコードを更新/削除したら、子テーブルの外部キーの値を NULL に設定する。
これにより、当該レコードの親子関係が解除されることになる。

たとえば、ブランド（親テーブル側）を削除したとしても、取扱商品（子テーブル側）は将来の管理用にデッドストックとして残しておく場合がこれに相当します。

親テーブルの主キーを変更した場合、および親レコードを削除した場合の外部キー制約の振る舞いを表にすると、以下のようになります。

動作条件	挙動	親（子なし）	親（子あり）	子
On Update	RESTRICT/NO ACTION	親主キー更新可	親主キー更新不可	変化なし
	CASCADE	親主キー更新可	親主キー更新可	外部キー連動更新
	SET NULL	親主キー更新可	親主キー更新可	外部キーNULL
On Delete	RESTRICT/NO ACTION	親レコード削除可	親レコード削除不可	変化なし
	CASCADE	親レコード削除可	親レコード削除可	子レコード連動削除
	SET NULL	親レコード削除可	親レコード削除可	外部キーNULL

【SQL による外部キー制約の例】

前述の外部キー制約のパターンのうちのいくつかを、実際の SQL による定義でいくつか確認してみましょう。太字が外部キーの設定と制約を定義している部分です。特に赤字の部分に注目してください。

挙動については、前項のテーブルをご覧ください。

例1:
On Update: NO ACTION

On Delete: CASCADE

-- Table structure for table `取扱商品`

DROP TABLE IF EXISTS `取扱商品`;

SET @saved_cs_client = @@character_set_client;

SET character_set_client = utf8;

CREATE TABLE `取扱商品` (

`ブランドID` int(11) DEFAULT NULL,

`商品ID` int(11) NOT NULL AUTO_INCREMENT,

`商品名` varchar(45) CHARACTER SET utf8 DEFAULT NULL,

PRIMARY KEY (`商品ID`),

KEY `fk_取扱商品_ブランド` (`ブランドID`),

CONSTRAINT `fk_取扱商品_ブランド` FOREIGN KEY (`ブランドID`) REFERENCES `ブランド` (`ブランドID`) ON DELETE CASCADE ON UPDATE NO ACTION

) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1;

SET character_set_client = @saved_cs_client;

例2:
On Update: CASCADE

On Delete: SET NULL

--
-- Table structure for table `取扱商品`
--

DROP TABLE IF EXISTS `取扱商品`;
SET @saved_cs_client = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `取扱商品` (
`ブランドID` int(11) DEFAULT NULL,
`商品ID` int(11) NOT NULL AUTO_INCREMENT,
`商品名` varchar(45) CHARACTER SET utf8 DEFAULT NULL,
PRIMARY KEY (`商品ID`),
KEY `fk_取扱商品_ブランド` (`ブランドID`),
CONSTRAINT `fk_取扱商品_ブランド` FOREIGN KEY (`ブランドID`) REFERENCES `ブランド` (`ブランドID`) ON DELETE SET NULL ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;

【関連リンク】
MySQL Workbench 基礎講習コース

2012-07-04

MySQL Workbench の EER モデリングツールでリレーションシップ検証 1 （Identifying と Non identifying）

MySQL Workbench の便利な機能に EER モデリングツールがあります。

MySQL Workbench の EER モデリング例

http://www.mysql.com/common/images/products/MySQL_Workbench_Visual_Design_Windows.gif

EER モデリングツールを使うことによって、データベースの基本設計を行い、それを使って MySQL 　データベース本体を生成したり（フォワードエンジニアリング）、既存の MySQL データベースを EER モデリングツールに読み込ませて（リバースエンジニアリング）設計内容を修正した後で再び MySQL データベースに同期（シンクロナイジング）させたりすることができます。

EER モデリングツールの魅力は、何といってもデータベース設計を視覚的に行えるところにあることでしょう。
テーブル定義、列定義はもちろんのこと、テーブルオブジェクトの配置、リレーションシップの設定などもマウスクリックや簡単な入力作業である程度の設計が可能です。

MySQL Workbench は、MySQL の公式サイトからダウンロードできます。

ダウンロード先：MySQL Workbench 5.2

今回より、MySQL Workbench の EER モデリング機能で設定可能なリレーションシップの種類と、その動作の違いについて数回に分けて説明します。

リレーションシップの種類には、一対一、一対多、多対多、自己リレーションなどがありますが、それらの基本的な概念は他のサイトでも多く触れられているため、本記事では省略します。

【Identifying と Non identifying】

EER でリレーションシップ設定を行い、外部キーの設定情報を確認したときに以下のようなチェックボックスが気になった方もいらっしゃるのではないでしょうか。

そこで、今回は、上記のリレーションの外部キー属性となる、identifying と non identifying の違いについて説明します。

Identifying relationship （依存リレーションシップ）--- 子テーブルの外部キーの一部に親テーブルの主キーが組み込まれた形となり、親テーブルなしでは成り立たない関係。

たとえば、ブランド契約で販売する商品が、撤退時に商品の取扱いも同時に終了するように、ブランドテーブルと取扱い商品テーブルを関連づける場合、[商品ID] および[ブランドID] の組み合わせで外部キーを作り、[ブランドID] が存在しなければその商品は存在し得ないような厳密な設計を行います。

本来、子テーブル側の主キーは一つ（[商品ID]）ですが、依存型リレーションシップの場合は親テーブル側のIDを識別するための列（[ブランドID]）も主キー扱いとなりますので、上図のように子テーブルの主キーは二つとなります（どちらも欠かせません）。

　EERモデリングでは、identifying リレーションのコネクタは、上図のように実線で表現されます。

　この場合、外部キー設定がされている取扱商品テーブル構成をダンプ（SQL表記）させると、以下のようになります。
　太字表記の部分が今回のチェック項目になりますが、特に赤字の部分に注目してください。[商品ID] および [ブランドID] の両方が主キーとなっています。

--

-- Table structure for table `取扱商品`

--

DROP TABLE IF EXISTS `取扱商品`;

SET @saved_cs_client = @@character_set_client;

SET character_set_client = utf8;

CREATE TABLE `取扱商品` (

`ブランドID` int(11) NOT NULL,

`商品ID` int(11) NOT NULL AUTO_INCREMENT,

`商品名` varchar(45) CHARACTER SET utf8 DEFAULT NULL,

PRIMARY KEY (`商品ID`,`ブランドID`),

KEY `fk_取扱商品_ブランド` (`ブランドID`),

CONSTRAINT `fk_取扱商品_ブランド` FOREIGN KEY (`ブランドID`) REFERENCES `ブランド` (`ブランドID`) ON DELETE NO ACTION ON UPDATE NO ACTION

) ENGINE=InnoDB DEFAULT CHARSET=latin1;

SET character_set_client = @saved_cs_client;

Non identifying relationship（非依存リレーションシップ）--- 親テーブルの主キーと子テーブルの外部キーでリレーションシップを構築するが、子テーブルに外部キーとは独立した主キーを持っている関係。

前述のモデルの応用例として、ブランド管理が廃止され商品だけが残った場合にも、在庫商品を処分（販売）できるように、ブランドを問わず商品を管理して扱う場合は、親テーブルが削除された場合にも、子テーブルの商品だけは残して管理できるように設計します。

EERモデリングでは、non-identifying リレーションのコネクタは、上図のように破線で表現されます。

この場合、外部キー設定がされている取扱商品テーブル構成をダンプ（SQL表記）させると、以下のようになります。
太字表記の部分が今回のチェック項目になりますが、特に赤字の部分に注目してください。[商品ID] のみが主キーとなっています。

--
-- Table structure for table `取扱商品`
--

DROP TABLE IF EXISTS `取扱商品`;
SET @saved_cs_client = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `取扱商品` (
`ブランドID` int(11) NOT NULL,
`商品ID` int(11) NOT NULL AUTO_INCREMENT,
`商品名` varchar(45) DEFAULT NULL,
PRIMARY KEY (`商品ID`),
KEY `fk_取扱商品_ブランド` (`ブランドID`),
CONSTRAINT `fk_取扱商品_ブランド` FOREIGN KEY (`ブランドID`) REFERENCES `ブランド` (`ブランドID`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
SET character_set_client = @saved_cs_client;

【関連リンク】
MySQL Workbench 基礎講習コース

2010-10-07

『売上猫くん on MySQL』開発日記 - 番外13 - MySQL Workbenchの憂鬱（ほぼ私的メモ）

『売上猫くん on MySQL』の開発もようやく終盤戦に突入。いままでは root 権限を主に使用して開発をすすめてきたが、リリース版のテストを行うにあたり、できるだけリスクを伴わないユーザ権限を作成し、これによりテストを行わなければならない。

そこでユーザ・権限を“お手軽に”管理・変更できる筈の、MySQL Workbench の Server Administration 機能を使うことにしたが、実はこれが全く“お手軽”ではなかったという御笑いの一席。

MySQL Workbench Ver5.2.16 OSS Beta→5.2.28 CE へアップグレード
このアップグレードを行った途端、Object Browser に mysql / information_schema が表示されなくなる。　「なんかとんでもないことやったかなぁ…？」と思いつつも、　これは以下を見つけて解決。

Information_Schema and mysql databases not shown（http://bugs.mysql.com/bug.php?id=53154）

Please, check "Show Metadata Schemata" checkbox in the Query Editor group of the SQL Editor tab in the Workbench Preferences dialog box. Use Edit > Preferences... menu item to open it. Don't forget to click "Refresh all" in the Object Browser's context menu after that.

Server Administration機能を“リモート”から使用するにはSSHサーバが必要
5.2.28CEへアップグレード直後、元々Connection登録してあったリモートサーバについては、SSHサーバが無くても、Server Administration 機能を使用できた（ここが不思議なところ）。　ところが新規にConnection登録したリモートサーバについては、SSHサーバがないとServer Administration 機能は利用できない。
ちなみに、元々あったConnectionについても、“Store in Vault...”ボタンで登録してあるパスワードを消去してしまうと、それ以降はリモート接続できなくなってしまった。

FreeSSHd=SSHサーバを入れる
そんなわけで、MySQLを積んだリモートサーバにSSHサーバを入れることにする。
Windowsでフリーで利用できるなSSHを探してみると、FreeSSHd （FreeSSHd.exeのダウンロード）というのが簡単・お手軽らしい。　インストール方法はここ。
インストール時の注意は、

「Shell」ととももに「SFTP」も選択すること。
SFTPのタブの「SFTP Home Path」にmy.iniが入っているボリュームを指定する。例えば、my.iniがEドライブに入っているなら、「E:\」と指定する。

New Server Instance でエラー
さて、準備完了となり、“New Server Instance”を実行。ところが途中で下図のエラーが発生する。

Operation failed: File %ProgramFiles%\MySQL\MySQL Server 5.1\my.ini doesn't exist

というエラーが出る。　例によってググり、下記のサイトを見つける。

参考URL：
Workbench doesn't autodetect my.ini properly if %programfiles% not on C:
The second thing which was wrong, was the path to the my.ini file in MySQL Workbench. I have changed it from C:\Programme\mysql\MySQL Server 5.1\my.ini to /Programme/mysql/MySQL Server 5.1/my.ini
OS Language small problem - Server Administration
...someone pointed out that I could ignore this error and continue. This is not obvious. The error message should probably say "Warning", not "Error" and it should indicate that you can specify the exact location in a later step.

つまり上図のエラーが出たら、構わず“Next”をクリック。続くダイアログで［Change Parameters］ボックスをチェックして“Next”。　次のウインドウで「my.ini」の場所を“...”ボタンをクリックして指定する。

次に“OK”して、以下、指示に従いつつ最後までいく。
尚、ここでmy.ini を正しく指定しなくても最後まで一応たどり着くが、その場合は、“Manage Import / Export” を実行した時に、「Workbench "AttributeError:NoneType object has no attribute parametervalues」というエラーが出てしまった。　これでとりあえずは、Server Administration 機能をリモートからも使用できるようになった。

ここでは略したがその他にもエラーが出て散々。またまた2日を潰してた。Workbenchもそうだが、MySQL 関連を動かすのはやはり大変だわ。

土屋

関連リンク：『売上猫くん on MySQL』開発日記の記事一覧

登録: 投稿 (Atom)

メニューバー

2015-04-14

ファイル起動時にFileMakerからMySQLに投げられるクエリ

SET NAMES utf8 ［参考URL］

SET character_set_results = NULL ［参考URL］

SET SQL_AUTO_IS_NULL = 0 ［参考URL］

SET AUTOCOMMIT=0 [参考URL]

set @@sql_select_limit=DEFAULT ［参考URL］

SET SQL_MODE='STRICT_ALL_TABLES' ［参考URL］

SELECT TABLE_NAME, TABLE_COMMENT, TABLE_TYPE, TABLE_SCHEMA FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA LIKE 'easyinv15' AND ( TABLE_TYPE='BASE TABLE' OR TABLE_TYPE='VIEW' ) AND TABLE_NAME LIKE '郵便番号'

select database()

describe `郵便番号`

SHOW KEYS FROM `easyinv15`.`郵便番号`

2012-07-06

MySQL Workbench の EER モデリングツールでリレーションシップ検証 3 （リレーションシップアイコンの種類と使い方）

2012-07-05

MySQL Workbench の EER モデリングツールでリレーションシップ検証 2 （外部キー制約の種類と動作）

2012-07-04

MySQL Workbench の EER モデリングツールでリレーションシップ検証 1 （Identifying と Non identifying）

2010-10-07

『売上猫くん on MySQL』開発日記 - 番外13 - MySQL Workbenchの憂鬱（ほぼ私的メモ）

SET NAMES utf8　［参考URL］

SET character_set_results = NULL　［参考URL］

SET SQL_AUTO_IS_NULL = 0　［参考URL］

SET AUTOCOMMIT=0　 [参考URL]

set @@sql_select_limit=DEFAULT 　［参考URL］

SET SQL_MODE='STRICT_ALL_TABLES'　［参考URL］