タグ

ProgrammingとDBに関するmaaa328のブックマーク (6)

  • SQLiteの注意点3つ!テーブル作成と同時にINDEX貼れないetc - Dance with Tech

    最近SQLiteを触っています。 基的な構文などはMySQLと同じですが、 決まりごとの違いや若干のクセがあるので、メモしておきます。 SQLiteのデータベースはファイルとして生成される SQLiteはデータベースをファイルとして生成します。 なので、「ファイルを消す=DBを消す」ことになります。 SQLiteをインストールしたら(最近のLinuxはデフォで入ってるぽい)、 以下のコマンドで、DBができあがります。 sqlite3 dbname.sqlite3 上記の「.sqlite3」の部分は何でもいいです。 しかし、拡張子がないと、 のちのち何のファイルか分からなくなる可能性があるので、 慣習的に「.sqlite3」とするようです。 しかし、DBを作成しただけではファイルが作成されません。 DBを作成し、さらにテーブルを作成しなければ、ファイルが生成されないようです。 「DB作った

    SQLiteの注意点3つ!テーブル作成と同時にINDEX貼れないetc - Dance with Tech
  • MS-Access を使わずに Jet Database Engine を使用する方法

    上記で「必須」になっているコンポーネントは、必ずしもダウンロードが必要であるという意味ではありません。 たとえば、Jet 4.0 SP3 は、Windows 2000 および Windows Millennium Edition (Me) には同梱されています。該当コンポーネントが既に存在している場合は、ダウンロードする必要はありません。 最近の OS であれば、何もしなくても動くでしょう。 HTA を使用する都合上、IE は Ver.5 以降が必須です。4.x 以下は不可です。 必須では有りませんが、VBScript を含む WSH(Windows Scripting Host)の最新版を入れてもよいでしょう。 2. VBScript with DAO 最初にご紹介する手法は、VBScript から MDB にアクセスし、結果を HTA(HTML アプリケーション)に表示するデモです。

  • エンジニアならこれ読んどけって本まとめ - だったらこうしてみたら?

    改訂:2014/10/20 備忘録としてまとめていきます。 今まで集めていた情報まとめていきます。 すでに読んだやつも今これから読んでこうってやつもまとめにまとめちゃいまっせ。 アウトプットも大事だけど、自分より先輩の方がアウトプットし続けて頑張って得た知見をあっという間にインプットできる""という形での学習も超大事なのです。 エンジニアとしての心得みたいな ハッカーと画家 コンピュータ時代の創造者たち 作者: ポールグレアム,Paul Graham,川合史朗出版社/メーカー: オーム社発売日: 2005/01メディア: 単行購入: 109人 クリック: 4,884回この商品を含むブログ (594件) を見る YCombinatorの共同設立者の彼の。 CODE COMPLETE 第2版 上 作者: スティーブマコネル,Steve McConnell,クイープ出版社/メーカー: 日

    エンジニアならこれ読んどけって本まとめ - だったらこうしてみたら?
  • 主キーはインデックスではない - 設計者の発言

    仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス(キー)というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルXがある。ところが、別のテーブルYからテーブルXの特定レコードにアクセ

    主キーはインデックスではない - 設計者の発言
  • データベースの内部動作を知る

    SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの? Part 1:SQL文はどのように実行されるのか SQL実行までの

    データベースの内部動作を知る
  • 複合主キーを避けるべき理由 - 虎塚

    データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 (2011/07/25 追記)複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり

    複合主キーを避けるべき理由 - 虎塚
  • 1