  |
はてなキーワード: rdbとは
SQL、JavaScript 、Excel VBA 、VB.NET、C#、Java。前者ほど触ってる期間が長い。SQLとJavaScriptが1年半くらい、Javaは参考書一冊読んだくらい。
Webで言うとフロントはAngularが少し分かる。サーバーはExpressが少し分かる。
RDBはテーブル15個くらいの社内向けWebシステムを一人で組んで現在半年以上運用中。今はテーブル40個くらいのシステム組んでるところ。
LinuxはUbuntuなら少し分かるけど、Docker周りは手を出したことがない。AWSとかGCPとかも分からない。
実務経験は無いに等しい。独学とプライベートの開発だけでこれまでやって来た。
できれば茨城県南だとありがたい。誰か雇って下さい。
外部キー嫌いがアンチパターンなのは同意だが、間違った外部キーの使い方するほうがよっぽどアンチパターンじゃないか？
外部キー貼らなかったことによって、俺はこんな被害だしたぜっての是非教えてほしい。
すぐに思いついたケースは
とかを思いついたがこんなケースで合ってるのか？こんなケースより間違った外部キーの使い方したほうが家に帰れなくなるケースのほうが多いと思うぞ。間違った使い方をしていて、システムが太ってくるとこんなケースが出てくる。
特に下2つは害悪で、SQLアンチパターンをコピペして、「おまえらw外部キー嫌いはアンチパターンだぞwww」ってやるのもいいけど、同じくらい間違った使い方を注意喚起したほうがいいと思うよ。DB識者のなかでは「そんなの常識w」かもしれないが何もしらない初心者が真似をしてお家に帰れなくなるのは辛くないか？
そんな経験していると、DB初心者は「せや！ユーザテーブルに退会フラグか論理削除フラグ持ったろwww うはw俺天才www」とかなって今度は削除フラグ持つなおじさんが出てくるぞ。しまいにはこれですよ。
http://b.hatena.ne.jp/entry/s/qiita.com/ponkotuy/items/6049388d564fb4385f4e
初心者どうしたらいいんでしょうね(*_*) 是非、DB識者には明るい未来を示して欲しいね。
俺？俺はAndroidのエンジニアでSQLiteは使わないから関係ないね。
RDB初心者の俺が恐れ多くも案を出すと、FKを作成する前に、そのテーブルの性質を予測することが大事なんじゃないかね？大量に発生するログデータなのか、大事なトランザクションデータなのか、第2正規化しただけのただの情報テーブルなのか。大事なトランザクションデータだったら親が削除された時にどこにどうやって退避するか。大量のログデータだったら、親が削除される時どうアプローチするか。とか恐れ多くも予測するね。
ちなみに外部キーないからER図出せないってのはそれはツールの作りであって、FK制約とは関係ないんじゃないの。バリデーション(外部キー)はセキュリティ対策(ER図を作成する)の為、実装するってのと個人的に同じことだと思っている。
日経xTECHの元記事を読んでもCOBOLの特徴があんまり伝わってこない感じだし、かといってそれをディスってもしょうがないので、書いてみた。
https://anond.hatelabo.jp/20190205192741
COBOLは本質的にはDSLなんだけど、一見汎用プログラミング言語に見えてしまってRubyやPythonなんかと比較するのが誤解のもとではあると思う。今の人でも知ってそうなCOBOLに似ている言語はたぶんSQLで、データを処理するための専用言語。ただ、SQLは頑張ればすごく複雑なこともできるパワフルな言語で、だからこそ現代でも生き延びているわけだけど、COBOLはわりとシンプルなデータ処理を想定している感じ。
SQLだけでアプリケーションを作れないのは触ったことある人なら誰でもわかると思う。普通はJavaやRubyで全体の流れを記述してデータベース入出力をSQLで書く。COBOLもそんな感じで、全体の流れをJCLやShellスクリプト、あるいはJP1のような運用管理ソフトで書く。SQLの1個の処理に相当するのがCOBOLのコンパイル単位で、それごとにソースファイルが分割される。ひとつのソースファイルに2個以上の処理を書くこともできるけど普通はしない。ここまで理解すると古いCOBOLに1ファイル内のすべての処理に影響するグローバル変数しかないのや、今のCOBOLにコンパイル単位をまたぐ真のグローバル変数がないのも、それほどクリティカルではないことがわかると思う。もし、本当に複数の処理にまたがる値が必要なら、データベースに格納してしまえばいいんだし。
で、SQLでいうところのデータベースに相当するのがCOBOLではデータファイル。sedやawkでテキストファイルやCSVファイルを行ごとに処理するのとちょっと似てるけど、COBOLの場合は固定長ファイルという点が違う。改行文字は入ってなくて、たとえば150バイトごとに次のレコードみたいな形式。これの1レコードごとに何月何日何時に〇〇という商品を□□円で売ったとか書いてあるのが典型的なデータの内容。それを集計して今日は〇〇が何個売れて売上がどれだけあったとか、出金合計がいくらで入金合計がいくらで、みたいな財務諸表を作ったり。SQLと同じように税率なんかが書いてあるマスタデータと、日々の売り上げが書いてあるトランザクションデータがあって、突き合わせたりということもする。こういう集計処理だからUIはなくて、夜中に自動起動するようなバッチプログラムが主な使われ方。（混乱するから余談だけど、今のCOBOLはSQLを使って普通のRDBにもアクセスできる。ただ使い方としては、RDB→ファイル処理→ファイル処理→ファイル処理→ファイル処理→ファイル処理→RDBみたいに、最初と最後だけみたいなのが普通）
入出力がファイルだから今の感覚で考えるとアクセスは遅い。でもメリットもあって、1回に1行しかメモリに乗せないからどんな巨大なデータでも時間さえかければ処理できる。それこそ国民ひとりひとりの年金データとかね。あと、途中でバグや不正データで止まってもデータを失うのは最小限で済むので復旧が比較的楽だったり。
データベースの話に戻ると、テーブル定義はどこに書いてあるかというとデータファイル側ではなくてCOBOLプログラム側、というのがSQLと一番違うところかも。つまり、このデータファイルの構造はこれこれこうなっていると想定して読みます、とソースコードに自分で書く。当然実際のデータ構造がそれと違ってたらおかしくなる。
まあそんな感じで80年代くらいに会計処理をする目的だったら悪い言語ではなかったので、銀行や官公庁とか、電力水道ガスといったライフラインを扱う大企業がこぞって導入して今に至る感じ。普通の大企業は途中でSunとかに置き換えてその後Linuxやクラウドにさらに置き換えたりしたけど、最初に作ったシステムが大きければ大きいほど、重要であれば重要であるほど現代的な環境に置き換えられないというのが今の課題。
同意。
ロック処理とか甘いしサイズ制限も2GBだしANSI SQLに一部対応してないしで、Webサービスのバックエンドに向かないのは間違いないが、さりとて5万行程度のテーブルを捌けない程無能なRDBでもない。
複数テーブルでもちゃんと外部参照設定して第3正規化するくらいは普通にできる。複数テーブルJoinしたりサブクエリ書いたりもできる。
元の発言した人は、ちゃんとAccessを使ったことがあるのか疑問である。
ただ、Excelよりも便利なのは確実だが、WordとExcelくらいしか使えない人も多いので、ほかの人とデータ共有するのであれば、Excelのままでもいいかな。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 86 | 15570 | 181.0 | 63 |
| 01 | 41 | 2954 | 72.0 | 40 |
| 02 | 15 | 2460 | 164.0 | 60 |
| 03 | 16 | 5067 | 316.7 | 38 |
| 04 | 19 | 3688 | 194.1 | 63 |
| 05 | 5 | 417 | 83.4 | 22 |
| 06 | 6 | 487 | 81.2 | 39.5 |
| 07 | 20 | 1497 | 74.9 | 35 |
| 08 | 34 | 5674 | 166.9 | 50 |
| 09 | 66 | 6624 | 100.4 | 35.5 |
| 10 | 92 | 9985 | 108.5 | 46 |
| 11 | 117 | 10209 | 87.3 | 50 |
| 12 | 116 | 13997 | 120.7 | 35.5 |
| 13 | 110 | 5844 | 53.1 | 32 |
| 14 | 142 | 12684 | 89.3 | 39 |
| 15 | 145 | 9551 | 65.9 | 33 |
| 16 | 148 | 9011 | 60.9 | 34 |
| 17 | 75 | 6396 | 85.3 | 35 |
| 18 | 161 | 23682 | 147.1 | 30 |
| 19 | 137 | 12711 | 92.8 | 42 |
| 20 | 75 | 10183 | 135.8 | 55 |
| 21 | 114 | 10938 | 95.9 | 35.5 |
| 22 | 110 | 10636 | 96.7 | 41 |
| 23 | 137 | 8276 | 60.4 | 32 |
| 1日 | 1987 | 198541 | 99.9 | 39 |
人(179), 自分(134), 話(86), 問題(81), 今(76), 日本(64), 仕事(64), 増田(60), 意味(58), 女(58), 男(55), 必要(50), ー(47), 人間(46), 気(45), 感じ(45), 前(44), 好き(43), 理由(41), 場合(40), あと(39), 相手(38), 子供(37), 関係(36), 存在(35), 金(34), 安倍(33), 他(32), 最近(31), 世界(31), 無理(31), 女性(29), 気持ち(28), 会社(28), 事実(28), 社会(27), 状況(27), レベル(26), しない(26), マイノリティ(26), 結婚(25), ネット(25), 普通(25), 完全(25), 別(25), ただ(25), 子ども(25), じゃなくて(25), 今日(24), 結局(24), 生活(24), 頭(24), 時間(23), 大学(23), 理解(23), 検索(23), 記事(23), 意見(23), お金(22), 絶対(22), 中卒(22), 親(22), 最初(22), ダメ(21), 個人(21), 自体(21), 作品(21), 言葉(21), 昔(20), 正直(20), 確か(20), 目(20), バカ(20), 件(20), 違い(19), 友達(19), 可能性(19), 人生(19), 認識(19), 扱い(19), 嫌(19), 全部(19), 障害者(19), 馬鹿(19), 内容(19), 一番(18), 毎日(18), 差別(18), 手(18), 主張(18), 逆(18), 権力(18), 批判(18), 情報(17), 場所(17), オタク(17), 普段(17), 世の中(17), サービス(17), 結果(16), たくさん(16), 顔(16), html(16), 嫌い(16), 全て(16), 質問(16), マジョリティ(16), 先(16), 現実(16), 平成(16), 家(16), 表現(16), 漫画(16), 日本人(16), マジで(16)
日本(64), 増田(60), 安倍(33), マイノリティ(26), じゃなくて(25), 障害者(19), 可能性(19), 平成(16), マジで(16), マジョリティ(16), 自民党(15), 低所得(14), アメリカ(12), なんだろう(12), ブコメ(11), PC(11), 元増田(11), 最低賃金(10), 物理法則(10), YES(10), 機械化(10), 二次創作(10), ワイ(10), はてなー(9), ようじょ(9), 健常者(9), 何度(9), 障碍者(9), 普通に(9), 2018年(9), 下方婚(9), な！(9), IT(9), ツイート(9), 米(9), ネトウヨ(8), いない(8), 共産党(8), DL(8), はてブ(8), トラバ(8), s(8), B(8), Google(8), Twitter(8), 関係者(8), ブクマ(7), アプリ(7), 東京(7), 一緒に(7), 自衛隊(7), 娘(7), 基本的(7), わからん(7), キモい(7), 石破(7), 筋トレ(7), twitter(7), 24時間テレビ(7), ブログ(7), SNS(7), にも(6), なのか(6), 発達障害(6), 1人(6), どんだけ(6), 好きな人(6), サーバルちゃん(6), Suica(6), RDB(6), pixiv(6), 真珠湾(6), 単純作業(6), 回転寿司(6), NHK(6), スマホ(6), RDBMS(6), タトゥー(6), 毎日(6), ？？？(6), 自然法則(6), ツイッター(6), A(6), アベ(5), 一般市民(5), さくらももこ(5), フェミ(5), 1回(5), ちびまる子ちゃん(5), ガチャ(5), ありません(5), ブクマカ(5), 1日(5), Amazon(5), 中国(5), 結果的(5), hatena(5), かな(5), 北朝鮮(5), お客さん(5), 20万(5), ちんこ(5), 障害者雇用(5), いいね(5), 艦これ(5), 2年(5), 被害者(5), 大五郎(5), はてな民(5), 個人的(5), LINE(5), スレ(5), 7%(5), 10人(5), ゴルドー(5), E(5), 民主主義(5), jsfiddle(5), 人間性(5), …。(5), 正義(5), 1割(5), 同人誌(5), 1件(5)
うんち (12), そうだね。うんちだね。💩 (3), パンティー (2), https://jsfiddle.n(2)
■世界三大ペンギン /20180829074002(11), ■[ゲーム]クイズ、検索したら１件しか出ませんでした /20180829140908(10), ■ /20180829165740(8), ■早稲田大学現代文芸コースのセクシャルハラスメント報告書がひどい /20180828223619(7), ■【思考実験】女はゴルドーを避けるのか？ /20180829123815(7), ■なんで漫画の実写映画は /20180829112319(7), ■anond：20180829183228 /20180829184256(6), ■ /20180829113426(5), ■【緩募】コミュニケーション不要な仕事【急募】 /20180829213909(5), ■外人って寿司おいしいって思うのかな /20180828164004(5), ■沸騰した味噌汁 /20180828153328(5), ■ワイシャツってクリーニングに出す物なの？ /20180828221836(5), ■揚げ物 /20180829141503(5), ■anond：20180829154129 /20180829154559(5), ■増田って /20180829004704(5), ■娘ちゃんとうんち /20180829125723(5), ■お見合いするべきか？ /20180829205310(5), ■保護猫さんを飼いたい /20180829081201(5), ■ナンパは軽薄で犯罪的な行為なのか？ /20180829222920(4), ■anond：20180829185836 /20180829190637(4), ■ /20180829121011(4), ■はてな民繊細チンピラ多すぎ問題 /20180829125728(4), ■卵かけご飯 /20180829122540(4), ■ネット上の艦これコミュニティまとめ /20180829031342(4), ■ /20180829111343(4), ■平成が終わる という表現 /20180828120344(4), ■日本人の字幕への意識の低さは何なん？ /20180829155850(4), ■anond：20180829182954 /20180829183228(4), ■筋肉っていつからブームになったの？ /20180828201927(4), ■はてな民のVtuber知識がガバガバ /20180829162352(4), ■anond：20180829161508 /20180829161634(4), ■風邪に幼女って効果あるの？ /20180829094551(4), ■ /20180829140907(4), ■いい歳してコンビニで立ち読みしてるおっさん /20180829083418(4), ■24時間テレビを叩いている方へのお礼 /20180829112304(4), ■フリーアーチャーにならなきゃよかった /20180828115851(4)
5555667(3158)
なる。IoT機器の定点データを保存する、ってことを考えたら確かにRDBじゃきつくもなるわな。
zabbixですら結構ヒーヒー言ってるのに60秒ポーリングで10万ユーザとかじゃ確かに無理だわ。
実サービスではそういうメトリクスってどういう扱いにしてんだろうな。消えてもいい扱い？
いやー、RDBMSの上位互換的な概念ワードは今のところ聞いてないで。
ざっくりNoSQLって括りは「RDBのそれぞれの機能に特化した」ようなものとして、
RDBMSは（速度以外に於いて）それらNoSQLで補っている全機能が入ったパーフェクトな何かって扱いなのは変わっておらんやろ。
言うてNoSQLでアクロバティックなトランザクション処理するよりは大人しくRDB使うやろ。
吾輩は無職である。職はまだ無い。どこで無職になったか、とんと見当けんとうがつかぬ。
何でも薄暗いじめじめした所で手斧を投げられていた事だけは記憶している。
しかもあとで聞くとそれは増田という人間中で一番獰悪な種族であったそうだ。
・・・・
まぁ、前置きの冗談はこの辺までとして、前々から作りたいな思っていた
Webサービスを中々時間が取れず作るのを諦めていたのだけど、
僕自身、プログラミングを生業とする職業では無く、学生時代も特にプログラミングついて何か
始めたのが昨年末の大晦日ちょい前なので、約5ヶ月掛かり、当初想定していた期間より
かなりの時間が掛かってしまい、反省点等含めその辺の事を書けたらなと思います。
■やりたい事（実装した事）
・ゲームユーザー同士を繋げるマッチングサイト（出会い系ではないよ。）
・タグをつける
構成を書いた方が良いと思うので
以下になります。
■構成
--------------------------------------------
FW：Flask 1.0.2
ORM：SQLAlchemy 1.2.7
その他ツール等：Let's Encrypt/fail2ban/等々
--------------------------------------------
ほぼ、既存のベーシックなサーバーサイド側の制御のみです。（jsで非同期通信はしてます）
変えるのもなと思い、取り敢えず上記です。
■選定理由
Railsの名前を良く聞くのでRuby on Rails触ったのですが、
Railsには馴染めなかった（扱えなかった）ので
何かマイクロFWの方が良いのだろうと、Sinatraいこうか思いましたが
Railsの印象が強く残った為、Rubyは止めてPythonに移りました。
今度は初っ端からマイクロFWが良いだろうとFlaskのサンプルを試すと
比較的プログラミング初学者でも扱いやすく覚える事も少ないので、PythonとFlask
の組み合わせで決定。
（気軽にプログラムを書け、自分がイメージしている処理や制御を素直に実現できる点が
書いていて気持ちが良いです。まぁ分からない所も有りますが、そう思わせてくれる点
が良いです。モチベーション的に）
NginxとuWSGIの組み合わせはFlaskで検索すると一番でてくるのでこれに決定。
SQLite3 はマイクロFWだから軽めのDBでたぶん大丈夫だと思ったのでこれに決定
■開発概要
・まずPythonの開発環境を整えようとなり、WindowsにVagrantをインストールして
仮想マシンの環境構築。ゲストOSの中にPyenv等を入れPython環境構築
・上記構築後に取り敢えず小さなサンプルから作ろうとなり、簡単なCRUDをFlaskで行える様にしました。
これができた時は嬉しかったです
・上記が出来てから、本番の開発に移りCRUDをベースにひたすら肉付けていく
→ユーザー登録機能作成/ログイン機能作成/ユーザー情報表示/編集機能/チケット作成/及び編集/バリデーション
・細かいViewの調整とスマホ用のViewも作成（レスポンシブルでは無いので）
・本番用のさくらVPSに環境構築とセキュリティ用のツール導入とLet's Encryptでhttps化
■悩んだ点/反省点
・悩んだのがタグ機能周りになるとどうすればよいか、かなり悩みました。
結論を言うとToxi法を使用しましたのですがここにたどり着き、理解するのに結構時間がとられました。
また、実装したらしたで、今度はそのタグ機能を検索するとなると検索ワードが1つとは限らないので
クエリーを動的に生成する必要が有り、これも実装するのにかなり時間が掛かりました。
SQL文だけならば比較的すぐに検索でヒットしますが、それをSQLAlchemyでどう実現すれば良いか分からず
かなり時間が掛かりました。DB設計やSQLAlchemyの文法に自信は無いですねぇ。。
・1次情報のリファレンスからは情報得ることがほとんど出来ず（たまにはできたが）、
Stack OverflowとQiitaと個人ブログが無ければこのサイトできなかったので
■総評
・5ヶ月と時間が掛かりまた反省点も多々有るが、とりあえずサービス公開まで
もっていけた事が嬉しいです。ただただ嬉しい。
・FlaskとSQLAlchemyの情報が日本語が少ないので公式リファレンスとStack Overflowを
行ったり来たりしたおかげで英語アレルギーがそこまで無くなった。
■成果物
オンラインゲーマー向け（e-sports）のマッチングサイトになります。
名前が安直で小学生が5秒で考えたような名前ですが、安直で気に入っています。
作った理由は、僕はBF1が好きなのでオペレーションキャンペーンと言うモードを
やろうとしたのですが、時間帯が悪いのか過疎なか分からないが全然マッチングしないのですよ。
やりたいのにマッチングしないので出来ないどうしよう、と。
また、昔セールでFarCry3をかなり昔に購入した時（既に4が発売済み）にCO-OPモードが全然マッチしない事が有り
旬が過ぎたオンラインゲームは中々マッチしなくてほぼシングルモードしか出来ない事は割とあると思うんです。
今だとBF4もかなり人数がいない状態なので特定マップのみとか。
なのでオンラインゲームでマルチプレイやCo-opで人を集めたい時、PUBGやFORTNITE等バトロワゲームのスクワッドを
募集する時、オンラインゲームの大会（e-sports）を開きたい時に利用して貰えると嬉しいです。
主に想定ユーザーと考えているのは、FPS/TPS/RTS/MOBA等のPCゲーマーをメインに考えていますがCS機やTCGでも
使って貰えると嬉しいです。
あとViewがレスポンシブでは無く、PC用とスマホ用しかなくタブレット用の中サイズのViewが無いのでご了承下さい。
遊んでも良いよという奇特な方がいましたら当該サイト内でコメント頂けると幸いです
・BF1（PC版）
それでは長々とありがとうございました。
・・・・
日月を切り落し、天地を粉韲して不可思議の無職に入る。吾輩は死ぬ。
ありがたいありがたい。
ScalaとかKotlinとかいろいろ言ってる奴いるが10年後にはどうせJavaが勝ってる。
Javaはnull安全じゃない！とかほざく奴はもちろん@CheckForNullアノテーション使ってから言ってるよな…？
フレームワークは流行り廃りがあるから微妙だが、勉強するならSpringにしておけ。それだけでいい。
Webブラウザに標準搭載のJavaScriptが無くなることもまずありえない。
あとやるならjQueryね。AngularJSとかすぐ廃れるから。
学習コストが高いものって結局広まらないからさ…素直に現実を認めよう。
AnsibleやFabric使ってるやつがいるがどうせ10年後にはブームが去り技術的負債となっている。
シェルスクリプトで代用できるのだからシェルスクリプトでやっておけ。
これだけ広まったRDBが今後使われなくなることはまず考えられない。
実験結果を解析するプログラムをCで書き、解析結果をgnuplotでグラフ化し、グラフを貼り付けたレポートをTeXで作成するのを、全てemacsだけで行うという、今思うと労力だけは修行僧並みの苦行をこなしていた。
結局、このスタイルは修士論文を書き逃げするまで続くことになる(論文の図表は当然のごとくtgif)。
「役に立つけど、死ぬほど使いにくい」とはどういうことかを身を以て経験した感じである。
しかし、この修行もどきが原点になったおかげか、今流行のWeb系の諸々の技術は、さほど難しいと思わなかったり。
また、就職後に経験したオブジェクト指向もシステムプログラミングも難しいっちゃ難しかったが、なんとか投げ出さずに仕事をこなせたのは上述の経験が肥やしになったからかも。
一方で、同じ頃に知ったRDBの、その恐ろしく合理的で分かりやすい思想に感動したり、ここ数年コーディングで小技的に使うMapとReduceをコンピュータ科学の素晴らしい成果だと本気で思えたりしたのも、出発点のハードルがやたら高かった故な気がしている。
しかし、それを踏まえても、あいつらの使いにくさはどうにかならなかったのか。
「役に立つのがそれしかないから泣く泣く使う」なんて、経験しないで済むならそのほうがいいに決まっている。自分が怪我の功名的な肥やしにできたのも結果論でしかないし。
てか今時の学生は、こういう作業に何を使っているんだろう。
アルゴリズムがわかってるにこしたことは無いけど「コンピュータってやつの根っこ」ってそれだけじゃないし。
コンピュータアーキテクチャとかネットワーク/プロトコルとかもわかっててほしいし、各種OSでそれぞれのコマンド使って情報引き出すノウハウも持っててほしいし。
プログラムに限定しても、アルゴリズムの知識以上に、名前付けのセンスとか、分割・整理のセンスも重要だと思うし。
データベースの設計だって、アルゴリズムがわかればできるってもんでもないし、業務ロジックと独立に正規化して設計するのが原則のRDBと、あらかじめクエリを想定して設計するドキュメントDBだと、全然考え方が違うし。
オープンソース活用にしても、今のフレームワーク・ミドルウェアって、アルゴリズムレベルの知識だけじゃあ、ソース読んでも設計思想とかわからなくてPoEAAとかのアプリケーションアーキテクチャの設計の知識も必要だし。
実際使おうと思ったら、ソース読むだけじゃなくて、ドキュメントや開発者ブログやメーリングリストもチェックするべきだし。
色々考えると、英語、ソースコード、問わずに原典にあたって必要な知識を増やす姿勢と、それを整理して伝える力が重要ってことになる。
http://anond.hatelabo.jp/20140905175927
エクセルは表計算ソフトだ！と言い他の使い方を認めない人は宗教ぽくて怖いです。
視点も狭く融通がきかなそうなので、モテないでしょうね。たぶん童貞です。
DBをエクセルにするかアクセスにするか他のRDBMSにするかは要件次第です。
RDBの知識がある方は、無駄にアクセスを使おうとすることもありますが、
全体の効率を考えたらエクセルの方がはるかに良い場合もあります。
（もちろんデータ量や入力状況によってはアクセスを検討すべき可能性もあると思います）
ケースバイケースなので、「エクセルは表計算ソフト」だといい除外する視点の小ささは
股間の小ささに繋がります。
視点がゴリゴリに凝り固まってて、他者の視点で考えられない童貞は、
RDBでリレーションできても女の子とリレーションすることはできませんよ。
byみおり
最近、地方→中央省庁のとあるデータのやりとりが、Accessベース（Access＋VisualBasic）からExcelベース（Excel＋マクロ）に変わったんだが…。
うちの県ではVisualBasicのランタイムを作業用ＰＣにインストールするだけで折衝に一年越しだったから、一応変更自体は歓迎だったんだけれども、これが…。
ちなみに、扱うデータ量は、ざっくり言って、一都道府県当たり平均で5000行×1000列の表くらい。多い都や府なら、列の方がこの数倍行くだろうな。で、あくまで個人的な感想として、どんな感じかつーと、
(1)データ触ったり集計したりしにくくなった。
前のシステムは、データ自体は単なるAccessのデータだったので、間違いを修正したり別の集計に使用したりが意外と気楽に出来た。
今度は、Excelを無理矢理マクロやらで動かしてデータベース化してるから、Accessの時代よりも途中でデータが触りにくくなった。で、データにミスがあれば、いちいち一番大元の支所の担当者に連絡して最初の打ち込みデータから変更して貰わないとならない。
(2)めちゃくちゃ重くなった。
これは、まあ想像つくと思うけど…重い。Excelとはいえファイルが数十メガとかあって、デカいから扱いに困るし、重さについては、特にデータから選択して表示させる機能が弱いらしく、やたらに時間がかかる。これが結構致命的かも。支所に配付した入力システムですら、４年前のPCではフリーズしまくった（新しいＰＣ使えと言ったら、結局個人用のＰＣ使ったとかいう噂も……ウソでしょ？）。県庁での取込・集計システムは、取り込んだデータの10支所ごとのまとめ表を閲覧表示しようとするだけで大体数分かかる。なお、一支所毎に表示する機能がないので（なんだそれ）仕方なく、支所ごとに、システムから一覧表（紙）を打ち出して送付してもらっているが（なんだそれ）、そうなると今度は、データと紙が一致しないという事例が発生した。表示機能が特に重いので、先方でも、データの中身は余り見ずに送ってるらしく、最終段階でデータいじったのを忘れたりしてそういうことが起こるらしい（なんだそれ）。
これは仕方ないことだが、RDBなら元々ソフトの機能でしていることをマクロでやらせてて、そこを触られたくないからだろうが、やってることの中身が把握できない。で、たとえばデータ保存の際にいろいろエラーメッセージが出ることがあるんだが（２年前のシステムで、標準で.xlsで保存する仕様になってるため、「機能低下が云々」とか）、おそらく問題なかろうとは思いつつも、不安なまま運用してる。
エクセルだから、入力とか扱いとか、気楽になった部分は評価する。なので、データベースとしての運用を想定したＤＢ機能強化版のExcel Proとか出ないものか？ と。
