- 投稿日：2019-03-01T23:37:55+09:00
MySQLのファイル周り(5.6)
公式ページの存在を知ってわかりやすかった事と主な関連パラメーターも合わせて見たかったのでまとめ。色々足りないと思うので気がついたらアップデート。
あとエクセルで作成やめたい。
テキストボックスを縦書き出来るサービスないかな
innodb_change_buffer_max_size: buffer pool内での割合
- 投稿日：2019-03-01T22:23:42+09:00
FileMakerとの幸せな関係（GoogleForm編）
前置き
前置きはいいよという方は、GoogleForm のデータをFileMakerに取り込む３つの方法からご覧ください。
社内SEの味方
中小規模の社内SEとして働いているのですが、慢性的にリソースが不足していることもあり
様々なサービスやソフトウェアに助けてもらいつつ日々課題に取り組んでいます。この記事では日頃の感謝も兼ねて GoogleForm と Filemaker について、特にその連携について紹介します。
GoogleForm
説明なんて不要ですね。
ちょっとしたアンケートや申請受付を作るのに手軽で便利なGoogleForm。
私たちもよく助けてもらっています。「こんなシステムが欲しいんだけど」という社内からの要望にも「それ、GoogleFormでよくない？」という場面は結構多いです。
弱小エンジニアだからこそ1、三大美徳の 「怠惰」 には全面的にしたがわねばなりません。
また、ピティナには「自分で作ってね」という 「怠惰」 もあります。
※ラリー・ウォールの「怠惰」からは外れますけどねどちらの意味においても、GoogleForm は大変魅力的です。
FileMaker
「自分で作ってね」の点でいうと、FileMakerというソフトウェアも大変重要な存在です。
というか、FileMakerがあったから「自分で作ってね」という怠惰が許されています。FileMakerについては少し説明します。
ViewとModelが一緒くたになったという感じなのですが・・・
- テーブルを定義すると、レイアウト画面でオブジェクトとして扱うことができる
- これにより、GUIで簡単にそれっぽい画面がめちゃめちゃ手軽に作れてしまう
というのがシンプルな説明でしょうか。
また、（ほぼ）日本語で記述できるスクリプトも搭載しているので、非プログラマーによるプログラミングが可能になっているのもポイントです。
イメージ
※FM17のサンプルファイルから拝借
右側に見えているのがテーブル定義用の画面で、左側がレイアウト（画面）設定画面です。カラム（FMではフィールド）をGUIでラベルやテキストボックスとしてレイアウトすることできるので、
簡単に画面が出来てしまいます。ピティナではFileMakerが基幹
私の働く ピティナ はこのFileMakerが基幹DBとなっており、社内システムの大半がFileMakerで構築・管理されています。
そのため、ピティナのシステム開発は「（なるべく）すべてのデータをFileMakerで見られるように」というのが暗黙の前提になっています。
GoogleFormとも仲良くしてほしい
なので、両者にはぜひ仲良くしてもらいたいのですが、GoogleForm と FileMaker はお互いのことを
気にしていませんので、デフォルトでは連携することができません。GoogleForm のデータをFileMakerに取り込む３つの方法
前置きが長くなってしまいましたが、ここから本題です。
これまで連携させるために行ってきた方法と、いまいま「これがベスト」と思える方法について紹介します。
①CData を利用する
手動コピーをしていた時代もあったのですが（恥）、最初に行き着いたのがCDataでした。
概要
- CData
- ライセンスの購入
- ローカル端末
- ODBCドライバに設定する
- FileMaker スクリプトを作成する（当該端末でないと作成できない）
- 専用のスクリプトステップでインサートSQLを作成する
メリット
SQLが使える
SpreadSheetをテーブルとしてみなしSQLで任意のデータを取得できます！！デメリット
設定が面倒
割とブラックボックスなUIなので、テーブル・カラムの指定方法が分かりにくいです。
一旦SQLを自動生成させて「ああ、こうやって書くのね」というのを掴んでから、
SQLを調整する感じになります。ライセンス料金
そこまで高価でもありませんが、後述の方法は特別な支払いがなく出来る方法なので、比較すると高く感じてしまいます。
＞ お値段表端末が限定される
これもライセンス料金の影響なので、お金を払えば解決する問題ですが、
目先の料金を小さくしようと思うと端末１台にのみ適用することになります。するとスクリプト修正・新規スクリプトの作成は、その端末で操作しなければならなくなり、
圧倒的に開発効率が悪くなります。まぁ、、、お金を払って複数台に入れればいいんですよ。
②GAS＋FM「レコードのインポート」
概要
- GAS
- スプレッドシートでcss出力マクロを作成する
- FileMaker
- WebViewerか何かでマクロ実行URLを叩く
- ローカルにcssが落ちてくる
- スクリプトでcssを「レコードのインポート」する
メリット
無料
自分で作れるので無料です。（開発コストはどれも大差ないので無視します）GAS楽しい
プラットフォーム機能が改善されてプロジェクト管理できるようになりましたね。
やばいです。GAS開発がどんどん楽しくなってきてます。デメリット
cssが邪魔
実ファイルを生成するので定期的に削除してあげる必要があります。
そこまで気にならない人もいるかと思いますが、やはりゴミになるものは作らないに限ります。③GAS＋MySQL
現時点でのベストだと思っています。
もっと早く気づいてもよかったのに・・・。悔しい限りです。GASの初期はMySQLへのインサートが出来なかったか、あるいは僕が情弱過ぎてリーチできなかったかで、
「できたらいいのにね」という話で終わっていました。概要
- MySQL
- DBサーバをたてる or 既存のDBサーバに１つテーブルを作成する
- ユーザを作成する（当該フォーム専用のユーザ）
- GAS
- MySQLにインサートするマクロを書く
- FileMaker
- MySQLをESS透過する
メリット
MySQLにデータがある
FileMaker 大好きな組織で働いていますが、僕自身は実は苦手です。
（リレーションを貼るのにいちいちオカレンスなるものを作成しないといけないとか・・。）なので、MySQLにデータがあるとすごく安心します。（SQL使えるし）
またFileMakerはデフォルトでMySQLとの連携があるため
- 透過してMySQLのデータを見ることができる（データはMySQLにのみ保持）
- FileMakerへの取込も標準対応（FileMakerのテーブルと同等に扱えます）
- ということは社内のスタッフも間接的にMySQLを扱うことができるのです。
データ量が多くなると、FileMaker越しにMySQlを見るのは辛くなってくるのですが、
GoogleForm で集める程度のレコード数なら問題にはなりません。デメリット
サーバ代
DBサーバがあって相乗りするなら不要です。GASに接続情報を書かないといけない
個人の感覚ですが、なんとなく気持ち悪いと思ってしまいます。
そもそも、当該ユーザは当該フォーム用のテーブルしかアクセスできないようにしますし、
公開されるわけでもないんですけどね。
古い人間の感覚かもしれません。データの多重管理
スプレッドシート、MySQL、FileMakerと下手すると三重持ちになります。
なので、FileMakerにはデータを入れず、MySQLをESS透過するのが良いと思います。ピティナでの使い方
- MySQL
- DBを１つ作成（GoogleFormの回答テーブルをまとめるDB）
- テーブルを１つ作成（GoogleForm１つにつき、１テーブル）
- ユーザを１つ作成（2のテーブルしか触れないユーザ）
- GAS
- 当該テーブルにインサートするGASを作成
- FileMaker
- 当該テーブルをESS透過
おしまいに
ピティナの場合は、
- エンジニアの都合（FM好きくない。MySQL好き）
- 事務スタッフの都合（MySQL好きくない。FM好き）
両方かなえようとしているので、③がベストですが、MySQLを必要としない組織であれば①か②が良いと思います。
①は多少SQLが出てきますが、おそらく一番単純なセレクト文しか使わないので、
SQLはじめての方でもQiitaの記事を参考にすれば対処できるでしょう。※ちなみに、いずれの方法を取るにしてもフォーム毎に開発コストが掛かりますので、その点は留意なさってください。
わたし個人のことであって、ピティナ・エンジニア全体のことではないですよ！ ↩
- 投稿日：2019-03-01T22:23:42+09:00
FileMaker 外部サービスとの連携（GoogleForm編）
前置き
前置きはいいよという方は、GoogleForm のデータをFileMakerに取り込む３つの方法からご覧ください。
社内SEの味方
中小規模の社内SEとして働いているのですが、慢性的にリソースが不足していることもあり
様々なサービスやソフトウェアに助けてもらいつつ日々課題に取り組んでいます。この記事では日頃の感謝も兼ねて GoogleForm と Filemaker について、特にその連携について紹介します。
GoogleForm
説明なんて不要ですね。
ちょっとしたアンケートや申請受付を作るのに手軽で便利なGoogleForm。
私たちもよく助けてもらっています。「こんなシステムが欲しいんだけど」という社内からの要望にも「それ、GoogleFormでよくない？」という場面は結構多いです。
弱小エンジニアだからこそ1、三大美徳の 「怠惰」 には全面的にしたがわねばなりません。
また、ピティナには「自分で作ってね」という 「怠惰」 もあります。
※ラリー・ウォールの「怠惰」からは外れますけどねどちらの意味においても、GoogleForm は大変魅力的です。
FileMaker
「自分で作ってね」の点でいうと、FileMakerというソフトウェアも大変重要な存在です。
というか、FileMakerがあったから「自分で作ってね」という怠惰が許されています。FileMakerについては少し説明します。
ViewとModelが一緒くたになったという感じなのですが・・・
- テーブルを定義すると、レイアウト画面でオブジェクトとして扱うことができる
- これにより、GUIで簡単にそれっぽい画面がめちゃめちゃ手軽に作れてしまう
というのがシンプルな説明でしょうか。
また、（ほぼ）日本語で記述できるスクリプトも搭載しているので、非プログラマーによるプログラミングが可能になっているのもポイントです。
イメージ
※FM17のサンプルファイルから拝借
右側に見えているのがテーブル定義用の画面で、左側がレイアウト（画面）設定画面です。カラム（FMではフィールド）をGUIでラベルやテキストボックスとしてレイアウトすることできるので、
簡単に画面が出来てしまいます。ピティナではFileMakerが基幹
私の働く ピティナ はこのFileMakerが基幹DBとなっており、社内システムの大半がFileMakerで構築・管理されています。
そのため、ピティナのシステム開発は「（なるべく）すべてのデータをFileMakerで見られるように」というのが暗黙の前提になっています。
GoogleFormとも仲良くしてほしい
なので、両者にはぜひ仲良くしてもらいたいのですが、GoogleForm と FileMaker はお互いのことを
気にしていませんので、デフォルトでは連携することができません。GoogleForm のデータをFileMakerに取り込む３つの方法
前置きが長くなってしまいましたが、ここから本題です。
これまで連携させるために行ってきた方法と、いまいま「これがベスト」と思える方法について紹介します。
①CData を利用する
手動コピーをしていた時代もあったのですが（恥）、最初に行き着いたのがCDataでした。
概要
- CData
- ライセンスの購入
- ローカル端末
- ODBCドライバに設定する
- FileMaker スクリプトを作成する（当該端末でないと作成できない）
- 専用のスクリプトステップでインサートSQLを作成する
メリット
SQLが使える
SpreadSheetをテーブルとしてみなしSQLで任意のデータを取得できます！！デメリット
設定が面倒
割とブラックボックスなUIなので、テーブル・カラムの指定方法が分かりにくいです。
一旦SQLを自動生成させて「ああ、こうやって書くのね」というのを掴んでから、
SQLを調整する感じになります。こんな感じ
ライセンス料金
そこまで高価でもありませんが、後述の方法は特別な支払いがなく出来る方法なので、比較すると高く感じてしまいます。
＞ お値段表端末が限定される
これもライセンス料金の影響なので、お金を払えば解決する問題ですが、
目先の料金を小さくしようと思うと端末１台にのみ適用することになります。するとスクリプト修正・新規スクリプトの作成は、その端末で操作しなければならなくなり、
圧倒的に開発効率が悪くなります。まぁ、、、お金を払って複数台に入れればいいんですよ。
②GAS＋FM「レコードのインポート」
概要
- GAS
- スプレッドシートでcss出力マクロを作成する
- FileMaker
- WebViewerか何かでマクロ実行URLを叩く
- ローカルにcssが落ちてくる
- スクリプトでcssを「レコードのインポート」する
メリット
無料
自分で作れるので無料です。（開発コストはどれも大差ないので無視します）GAS楽しい
プラットフォーム機能が改善されてプロジェクト管理できるようになりましたね。
やばいです。GAS開発がどんどん楽しくなってきてます。デメリット
cssが邪魔
実ファイルを生成するので定期的に削除してあげる必要があります。
そこまで気にならない人もいるかと思いますが、やはりゴミになるものは作らないに限ります。③GAS＋MySQL
現時点でのベストだと思っています。
もっと早く気づいてもよかったのに・・・。悔しい限りです。GASの初期はMySQLへのインサートが出来なかったか、あるいは僕が情弱過ぎてリーチできなかったかで、
「できたらいいのにね」という話で終わっていました。概要
- MySQL
- DBサーバをたてる or 既存のDBサーバに１つテーブルを作成する
- ユーザを作成する（当該フォーム専用のユーザ）
- GAS
- MySQLにインサートするマクロを書く
- FileMaker
- MySQLをESS透過する
メリット
MySQLにデータがある
FileMaker 大好きな組織で働いていますが、僕自身は実は苦手です。
（リレーションを貼るのにいちいちオカレンスなるものを作成しないといけないとか・・。）なので、MySQLにデータがあるとすごく安心します。（SQL使えるし）
またFileMakerはデフォルトでMySQLとの連携があるため
- 透過してMySQLのデータを見ることができる（データはMySQLにのみ保持）
- FileMakerへの取込も標準対応（FileMakerのテーブルと同等に扱えます）
- ということは社内のスタッフも間接的にMySQLを扱うことができるのです。
データ量が多くなると、FileMaker越しにMySQlを見るのは辛くなってくるのですが、
GoogleForm で集める程度のレコード数なら問題にはなりません。デメリット
サーバ代
DBサーバがあって相乗りするなら不要です。GASに接続情報を書かないといけない
個人の感覚ですが、なんとなく気持ち悪いと思ってしまいます。
そもそも、当該ユーザは当該フォーム用のテーブルしかアクセスできないようにしますし、
公開されるわけでもないんですけどね。
古い人間の感覚かもしれません。データの多重管理
スプレッドシート、MySQL、FileMakerと下手すると三重持ちになります。
なので、FileMakerにはデータを入れず、MySQLをESS透過するのが良いと思います。ピティナでの使い方
- MySQL
- DBを１つ作成（GoogleFormの回答テーブルをまとめるDB）
- テーブルを１つ作成（GoogleForm１つにつき、１テーブル）
- ユーザを１つ作成（2のテーブルしか触れないユーザ）
- GAS
- 当該テーブルにインサートするGASを作成
- FileMaker
- 当該テーブルをESS透過
おしまいに
ピティナの場合は、
- エンジニアの都合（FM好きくない。MySQL好き）
- 事務スタッフの都合（MySQL好きくない。FM好き）
両方かなえようとしているので、③がベストですが、MySQLを必要としない組織であれば①か②が良いと思います。
①は多少SQLが出てきますが、おそらく一番単純なセレクト文しか使わないので、
SQLはじめての方でもQiitaの記事を参考にすれば対処できるでしょう。※ちなみに、いずれの方法を取るにしてもフォーム毎に開発コストが掛かりますので、その点は留意なさってください。
わたし個人のことであって、ピティナ・エンジニア全体のことではないですよ！ ↩
- 投稿日：2019-03-01T20:06:01+09:00
MySQLとPostgreSQLのALTER TABLEによるカラム型変更時の既存レコードの扱いの違い
どっちがどっちか忘れるので
問
ALTER TABLE後の型に変更前のレコードが相応しくない場合にどうなるか。結論
- MySQLはキャストを行う。(文字長なら切り詰めを行う)
- PostgreSQLはエラーを吐く
検証環境
mysql --version mysql Ver 14.12 Distrib 5.0.67, for unknown-linux-gnu (x86_64) using readline 5.1 psql --version psql (PostgreSQL) 9.2.18コマンド
mysql db -e "ALTER TABLE users CHANGE username username varchar(100) not null;" # 30文字以上のユーザー登録 mysql db -e "ALTER TABLE users CHANGE username username varchar(30) not null;" # エラーなし(ユーザー名は30文字まで右辺切り捨て) psql db -c "ALTER TABLE users ALTER COLUMN username TYPE varchar(100);" ALTER TABLE # 30文字以上のユーザー登録 psql db -c "ALTER TABLE users ALTER COLUMN username TYPE varchar(30);" ERROR: value too long for type character varying(30) # ユーザー削除 psql db -c "ALTER TABLE users ALTER COLUMN username TYPE varchar(30);" ALTER TABLE # または、明示的なキャストを行うと、mysqlのように切り詰められる psql db -c "ALTER TABLE users ALTER COLUMN username TYPE varchar(30) USING username::varchar(30);" ALTER TABLE参考
検索ノイズが多めだったのでここに残すことが目的
CHANGE または MODIFY を使用してデータ型を変更すると、MySQL は、既存のカラム値を新しい型にできるだけ変換しようとします。
警告この変換によって、データが変更される可能性があります。たとえば、文字列カラムを短くすると、値が切り捨てられる可能性があります。新しいデータ型への変換によってデータが失われる場合は操作が成功しないようにするには、ALTER TABLE を使用する前に厳密な SQL モードを有効にします (セクション5.1.7「サーバー SQL モード」を参照してください)。
これは、その列の既存の項目が新しい型に暗黙的キャストにより変換できる場合にのみ成功します。 より複雑な変換が必要な場合、古い値から新しい値をどのように計算するかを指定するUSING句を付けることができます。
切り捨てはしてくれても良さそうだけど。
- 投稿日：2019-03-01T12:18:40+09:00
mysql_secure_installation の初期パスワード確認
経緯
MySQLの設定をする際に初期パスワードが自動発行されていることを知らなかったため、記事に残しました。
Conohaのサポートブログ
https://support.conoha.jp/v/setupmysql/問題点
▼SQLのセキュリティ設定の際に下記のエラーで躓いてしまった
$ mysql_secure_installation Securing the MySQL server deployment. Enter password for user root: Error: Access denied for user 'root'@'localhost' (using password: YES)解決
どうやらSQLには初期パスワードが事前に発行されているようです。
初期パスワードの格納場所は/var/log/mysqld.log
▼root@localhost:の後ろが初期パスワードです$ cat /var/log/mysqld.log ~~省略~~ [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: [初期パスワード]▼
mysql_secure_installationで初期パスワードを入力し新しいパスワードを設定$ mysql_secure_installation Securing the MySQL server deployment. Enter password for user root: [初期パスワード] The existing password for the user account root has expired. Please set a new password. New password: [新しいパスワード] Re-enter new password: [もう一度新しいパスワード] The 'validate_password' component is installed on the server. The subsequent steps will run with the existing configuration of the component. Using existing password for root. Estimated strength of the password: 100 Change the password for root ? ((Press y|Y for Yes, any other key for No) : y New password: [新しいパスワード] Re-enter new password: [もう一度新しいパスワード] Estimated strength of the password: 100 Do you wish to continue with the password provided?(Press y|Y for Yes, any other key for No) : y By default, a MySQL installation has an anonymous user, allowing anyone to log into MySQL without having to have a user account created for them. This is intended only for testing, and to make the installation go a bit smoother. You should remove them before moving into a production environment. Remove anonymous users? (Press y|Y for Yes, any other key for No) : y Success. Normally, root should only be allowed to connect from 'localhost'. This ensures that someone cannot guess at the root password from the network. Disallow root login remotely? (Press y|Y for Yes, any other key for No) : y Success. By default, MySQL comes with a database named 'test' that anyone can access. This is also intended only for testing, and should be removed before moving into a production environment. Remove test database and access to it? (Press y|Y for Yes, any other key for No) : y - Dropping test database... Success. - Removing privileges on test database... Success. Reloading the privilege tables will ensure that all changes made so far will take effect immediately. Reload privilege tables now? (Press y|Y for Yes, any other key for No) : y Success. All done!