1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

MySQL のフロントにAccessを使う?

Posted at

結論、今回のプロジェクトでは 不採用。

中小企業のちょっとした業務システムの開発には、Accessがぴったりなケースが非常に多いと考えています。

Accessのメリット

数十年の歴史、情報が多い

学習コストが低く、使える人が多い

爆速で開発できる

プリンタとの相性が抜群に良い

Access2万円、配布用には無料のランタイムがあって低コスト

DBが1ファイルなのでバックアップ管理が簡単

Accessのデメリット

謎のクラッシュがまれに起こる ⇒ファイル分割で回避、バックアップデータ件数が数億件とかなってくると動作がモッサリ

ひととおりAccessで開発完了して、次のステップをいろいろやってたら将来見据えて… で、思いつくわけです。バックエンドMySQL、フロント Access。いいとこどりのいい案だと思うんです。ODBCドライバでの接続になり、多少の難点はありますが、エラー処理やら、各テーブルのタイムスタンプカラムやらひととおり対策すれば開発は容易に進みます。そしてAccessでのフロント開発はとにかく爆速。速い!

要求事項がここまでならおススメです。

が、今回のプロジェクトはレンタルサーバーのMySQLとレプリケーションがしたかった。業務で普段使いするLAN内のMySQLの一部の情報を、レンタルサーバー経由で公開したかったのです。でですね、

XServerもロリポップも、MySQLには外部から接続できません!

早く気付こう(^^;AmazonやSakuraに自分でDB立てるしかなさそう。パパっと完了したいので今回はパス。

Access爆速すぎてバージョン1をつくったあと、バージョン2もいちからつくっちゃったので、データモデルが設計当初よりかなり洗練されました。結果どうなったかというと、メインXServerにMySQL×Cakephp+ローカルAccess(MySQL使わず)となりました。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?