DBの勉強するから、見ててください

DBの勉強日記スレを立てました。ちゃちゃ入れてください。
（「スレ立て許可スレ」で許可を得た77です。）

DBの何を勉強するの？

SQL とかの文法？
ＤＢシステムの研究？
オラクルマスター取得？

まずは計画と目標を策定してください。

茶を入れました。玄米茶サイコ―。

PGじゃないですが、パソコン関連の職場にいて、CやJavaなら使えます。
でも、DBがマルキリパーなので、勉強しようと思い立ちました。
Access、MySQL、Postgre、Oracle、どれをやろうか考えて、まず、
Accessからはじめることにしやした。
勉強することにしました。Accessはクセがあるとの話でしたが、
まあ、一般的そうなので。

俺も勉強するからみんな励ませや！（俺を）

関係代数まずやれや。コッド正規形とかも覚えといたほうがええよ。

＞勉強人Ｘ
偽者が暴言を吐いて駄スレに転じる事が多いので、今のうちにトリップを
付ける事をお薦めします。

私もDBの勉強したいので、できれば勉強して理解した内容を書いて頂けると
非常に嬉しいんですが。。。がんばりましょう。

>>2 >>3
さっそく、レスありがとう。

今日は、お店に行って、OfficeXPと本を買ってきました。
OfficeXPは先ほどインストールに成功しましたが、うわさのアクチベーションで、
ちょっと、めげました。
本は、いなかの本屋でとりあえず売ってるのを買いました。よい本かどうかは、知りません。
「実用システムで学ぶAccess2000データベースシステム構築」荒井淳著
（あ、2000でやんの）で、今日は、DB作成、データベースウインドウで
デザインビュー呼び出し、テーブル作成までやってみました。

今日わかったこと：（情報処理2種で勉強したような）
表のようなもの＝テーブル
行＝レコード
列＝フィールド
感想：
とにかくテーブルの入ったDBが作れてうれしい。

何日で挫折するか賭けないか？>all

>>9
どんな形であれ、勉強をしようとする人間を
バカにする態度は感心されないと思われ。
そういう斜に構えた態度はみっともないよ。

6 だけど。
関係代数はやっといたほうがいいぞ、これをもとにして SQL は考えられてんだから。
そんなに難しいもんじゃないぞ。

＞表のようなもの＝テーブル
＞行＝レコード
＞列＝フィールド
俺もそれ習ったよ、お互いがんばろうぜ！
月曜からはSQLの文法を勉強します。

みんな、レスありがとう。もっと厳しいレスを予想してたのに。
トリップはやり方がわからないので、ご勘弁を。
一緒に勉強するという人、がんばろう！
関数代数って、えーと、テーブルの結合とか選択とかってやつですか？
もう少ししてから考えます。（俺、あんまり頭よくないんす。）
じゃ、今日は、落ちます。また（たぶん）明日。

6 じゃないけど、関係代数(Relational Algebra)だよ。関数代数じゃないよ。

レコード、フィールドは必ずしも一般的な呼び方じゃないよ
Accessはインスト時のセットアップとかほとんど無いから
楽だけど勉強にはならん。
Postgresあたり入れた方が勉強にはなると思うぞ。

DBって勉強するものだったのか…
オレは設計するものかと思ってた

>>10
激しく同意
向上心のないPGが実に多い。

>>15
Postgresは、日本語のドキュメントなんてWebにちっとしか
なかったころにFreeBSDに入れて格闘した。
結構楽しかったな。
後は、Oracleの評価版（90日の）でいろいろ学んだ。
期限過ぎると、またOSから入れ直したりして（ｗ

>>17
12日で挫折する方に賭けてるのに同意するのか？ｗ

>>1
あー、前スレでいいんじゃないとか言ったもんだ。
まさかACCESSになるとは思わなかったが。
ま、気合い入れすぎずに適当に頑張れ。

>>15
そうかな？
ＲＤＢ勉強するならＡｃｃｅｓｓって思うけど。
ビジュアル的にも分かりいいし。
（ＩＮＤＥＸとかは間違った知識が付きそうだけど）

>>17
微妙に釣られてるぞ。(w

>>1
> CやJavaなら使えます
ということだが…そうすると、
求められるスキルは、Access使いと言うより SQLとDB設計じゃないの？

Accessつーアプローチは悪くないとは思うけど、
AccessでDB設計して、あとは普段使ってる言語から
DBへのデータの追加、削除など SQLを使うための基本を押さえる方が
意味があると思うんだが。

それとも、Access使いになりたいだけ？
# それも生き方だが。

漏れはOracleとかお勧めするな
MSDEって手もあるな

＞前略Ｘ＆Ｍ（並べるとなんか変）
かむばってくださいいくつぐらいの人なのか解らないけど、新しい知識と技術を身につけよう
としている姿勢はすきです。

向上心極無のバカ後輩で苦労する後輩より５こ上のＰＧ

>>15
PostgresってWindowsだとNT用のバイナリしかないのでは（１さんはXP
みたいで。ちなみに2000だとインストールはできるが起動は必要なDLLが
ないと言われてできませんでした）。
フリーだとInterBaseあたりがいいのでは？
あとAccessは確かにSQLに方言があるので注意（IIFなど）。

Postgres+CygwinならコンパイルしなおしゃXPでも使えるんじゃないの？
まぁ一番いいのはOracleだけど

>>24
「ＳＱＬには方言がある」という事実を覚えるにもいいかも（ｗ

トランザクションとかも覚えられないかもなぁ。
ってロールバックとかなかったよね、Ａｃｃｅｓｓ？

DB2ってのもあるな
体験版が雑誌とかについてるね

OracleとSQL ServerとDB2のうち２つでも経験してればOK。
あとDBの勉強って言っても、データベース設計なのかSQLとかの
プログラミング周りなのかで全然違う。

SQLなんてのは簡単ですぐ覚えられるじゃん。
設計は実務で体験するのが一番分かりやすいんだけどなー。

あとOracleマスターの金以上を持ってると、知らない人にはそれなりに有効です。

でもOracleマスターって「Oracleのことを知っている」ってわけで、データベース
の設計もできるというわけではないので、それで変に期待されて設計を任せられ
ちゃうと痛いシステムができる場合も…。

WindowsならMySQLって選択もあるぞ。
あれもインストールは簡単だけどな。
でもユーザ管理とかの勉強もできると思う。
（Accessもできるんだっけ？よくわからん）
ただし機能は弱いけど。とっかかりならお金もかからずおすすめ。

>>26
トランザクション機能はありますよ。
構造的なトランザクションなんで、VBA で組ときはワリと便利。

とりあえず、AccessはＤＢを学ぶ上ではアレかも知れないけど、
SQL Server へとステップアップしていくのなら入門としては
悪くない。ＤＢ構築系の入門書なら触れているでしょう。

ただ、SQLを学ぶつもりなら、その辺りを隠してしまっている
分、逆に難しく感じるかもね。

素朴な疑問。
・どうしてインストが簡単だと勉強にならないの？
＃業務ではよくインストするものなの？

>>31
ＤＢはその構築も含めて勉強する必要があるから。

Accessも悪くは無いけど、実際に業務で使う可能性があるのなら
Oracleの方が色々得な事が多いかもね。この辺は業種によるけど。
ｶﾞｲｼｭﾂ風味だがPersonalOracleの評価版あたりなら
2000円前後のHowTo本に付いてくることが多いのでｵｼｼﾒ。
それこそ使用期限ごとにOSごと入れ直してもいいしね(^^;
LAN内にDBとOSだけって言うDB鯖を一個作るだけなら手間も大した事無いでしょ。
OracleのマトモなインストールはJavaなので激しくトロいが…(;´ω`)

どっかに学習用にＳＱＬとか叩かせてくれる公開サーバって
無いもんですかね。

WSH＋ODBCでなんとかならん？

AccessのVBAだけでもパーソナルな管理ツールぐらいでしたら結構なものが
作れるとは思うが。ただしAccess自体にバグが多いので気をつけて
（2.0のころよく言われたが今はどうなのだろう）。

結局Accessで勉強するのか？

VBやVC++もしくはdelやBuilderなどからの外部Attachから勉強した方が
よいのではないか？
結局はVBAでの使用はPersonalに限定されるだろうから・・・
DB設計って面から考えると確かにAccessでの勉強は無駄にはならんかも知れんが・・・

趣味のお勉強段階のうちにOracleのインストール/アンインストールはマスターしておきましょう（苦笑）
アンインストめんどくせぇ…

みなさん。レスありがとう。ほんとに勉強になるっす。

俺の会社は名目「ソフト開発」のはずだけど、社長以外実戦経験のある
PGはおらず、実態は「パソコンよろず相談」（＝IT社会の寄生虫？）です。
お客さんの要望で、ワードの使い方を教えたりもしてるんです（涙）。
将来の野望的には、OracleDBを外から操作するアプリを作ったりしてみた
いですけど。ODBCとかJDBCとかって言うんですか。

最近のお客の要望が、「DBを入れたい」（ほんとは、もっとぐちゃぐちゃ。
要約するとそうなる。もちろん、基幹業務系の話じゃない。というか
基幹業務なら受けれない）というものが多くなってきて、なんにしも、
Accessあたりからはじめるのが、仕事にも結びついているんです。

買ってきた本はサンプルを見ながら説明だったのに、サンプルCDを
いきなり置いてきてしまった。（たぶん、事務所）俺は、アホ。
でも、なんとかがんばろう。

クエリのところまで読んだ。クエリは、DBからデータを抽出することらしい。
そこで、2つのテーブル間にリレーションシップがある例があった。
リレーションシップは、「違うテーブルの同じものを結びつけるもの」
らしい。しかたがないので、自分で、例を作ってみた。
まず、テーブルのデザインビューでテーブルを2つ作った。

　テーブル名：社員名簿（フィールド：社員番号（数値型）、氏名（テキスト型））
　テーブル名：給料表（フィールド：社員番号（数値型）、給料（数値型））
ここで、2つのテーブルの社員番号が同じものだから、これらにリレーションシップを付ければよいわけだ。2時間くらい悩んだけど、メニューのツールで
リレーションシップを選んで、テーブルを2つとも追加にして、１つのテーブル
の社員番号をもう１つのテーブルの社員番号までドラッグすればよい（らしい）
とわかった。「結合の種類」にも悩んだけど、いろいろかえて、クエリで、

テーブル；クエリ１（社員番号、氏名、給料）

を表示したところ、両方の表にあるものを表示するか、どっちかの表のもの
は全部表示するかの違いとわかった。
ここまでできて今日は満足。というか疲れ切った。（今日はおしまいす。）

基幹業務でないなら、無理して馬鹿高いOracle使わずにすむかもしれないし、
Access→MSDE≒MS-SQL　という課程で正解では?

OfficeXPのAccessもMSDEついてくるよね?

>41
たぶん新しいＭＳＤＥがついてくるように思った。
　　　　　　　　↑同じマシンに複数インストできる奴

SQL叩きたいならLinux+Sybaseにしとけ。後者は本で売ってる。

ふぅ、なんかこのスレに触発されて久々に Oracle インストールしてるよ。
（数年前のキャンペーン中に買った、Oracle for linux 805ね）
さぁ、GOLD 取得に向けて俺も頑張るぞ。

8.0.5か？
さすがにそれは・・・

>>45
ダメすか？
今のマスターって９ｉまで行ってたっけ？

先月から9i対応の試験になったよ。

>>34
公開サーバー探すより、Oracle なり Interbase なり MySQL なりを
ダウンロードしてきてインストールした方が早くないか？
Oracle だって開発用のやつはただでダウンロードできるんだから。
（ただしむちゃくちゃでかい。CD ３枚分……）

　MySQL は SQL にくせがあるから、初心者向けではないかも。
サブクエリー使えないから、JOIN の使い方学ぶにはいいか（ｗ
Interbase でもいいんだが、やはり Oracle が一番かな。

Oracle今11i使ってるよ
もう少ししたらリリースされるんじゃない

>41
　Office2000のMSDE→SQL-Server7.0互換
　OfficeXP　のMSDE→SQL-Server2000互換。

　この差は結構大きいかも。

>勉強人X
　DBのとっかかりとしてAccessを選んだのなら、デザインビューに
頼っていてはダメ。SQLは必須になるんで、クエリー組む場合、
必ず「SQLビュー」で、どんなSQLが組まれているのか知れ。
　

>>35
TEXTのODBCを使えばCSVファイルの検索できるから
それこそDBなんていれなくてもSQLの勉強はできるな(w

確かにAccessのデザインビューにいきなり頼ってはいけません。
SQLの本を買ってきてクエリーのデザインビューを出したらすぐに
SQLビューを右クリックして出してSQLをちゃんと手打ちして実行
して結果を確かめてください。
そうじゃないと覚えないよ。

みなさん、いろいろありがとう。
SQLビューの話は、特に参考になりました。
やってみたら、SQLというものが出てきました。

SELECT 社員名簿.社員番号, 社員名簿.氏名
FROM 社員名簿 INNER JOIN 給料表 ON 社員名簿.社員番号 = 給料表.社員番号;

こんなの。俺は、GUI操作よりこういう方が好きです。ぼちぼち勉強します。

日記：
今日は、平日なので、あんまり勉強できなかったけど、
クエリのところを読んだ。（まだ、デザインビューっす。）
選択クエリはわかった。これはデータを抽出するもの。
テーブル作成クエリは、抽出した結果をテーブルにするもの。使えそう。
更新クエリ、追加クエリ、削除クエリはよくわからなかった。
こいつらは、クエリのテーブルでデータを与えないと、更新も追加も削除も
できないよう。でも、その場でデータを与えるなら、直接テーブルを編集
した方が速そう。なんでこんなのあるのかな？

パラメータクエリはおもしろかった。実行すると、ダイアログが開き、
パラメータを入力すると、そのパラメータを持つレコードが表示できる。

今日は、この辺。他のクエリはとりあえずいいや。
明日は、元気があれば、フォーム。
#レスと区別するため、はじめに「日記：」と書いてみました。
#うっとーしければやめます。
#あと、よければ、Mさんたちもここに日記書いてください。

>>54
良いんじゃない？
元々日記ｽﾚのつもりだったんでしょ？

おれはフィールド名に日本語をつかうかどうか迷ってるよ
USERID 会員番号
ZIPCODE 郵便番号
TEL 電話番号
たしかに日本語のほうが入力大変で実行速度遅くなるけど見やすいな

>56
あと日本語はシステム開発や移行の際に気をつかわなければならないな。
特に移行なんかはシステムがOSごと変わる場合もあるからな・・・
という理由で自分が最初から作る場合は日本語は使わないことにしてる。

RDBを操作するアプリをJavaなりCなりで組む場合、当然テーブルを手で
いじれるわけではないのでプログラムのほうからODBC、JDBC経由で操作
することになります。その際に更新クエリ、追加クエリ、削除クエリを
用いてテーブルデータのメンテナンスを行います。

まあテーブルデータのメンテナンスはバッチローディング（SQLServerでし
たらbcpなんていうユーティリティを使う）のみでアプリからは照会のみ
なんてのもありますが（この場合は選択クエリのみでも大丈夫）。

ですから更新クエリ、追加クエリ、削除クエリもしっかり覚えてください。

>58
なるほどっす。更新、追加、削除クエリも覚えます。
（お話では、GUIの形より、SQLとして、という気がしますが。）

日記：
今日は、フォームとレポート見た。
フォーム　＝　ダイアログ風のインターフェース
レポート　＝　印刷用のきれいなまとめ
といったところかな。
デザインビューとウイザードを使う方法はわかった。
フィールドをフォーム上にドラッグすると対応する
コントロールが現れるのはすごい。
嫌いな人と好きな人に分かれる気がする。

ページはあんまり興味ないから、明日はマクロかな。
VBAは挫折経験があるので、どうかな。

小さくてもいいから、それひとつで完結したＤＢを一度
作ってみるといいよ。

この日記もＤＢにしてみたら。

更新クエリ、削除クエリて何？
クエリって問い合わせって意味だぞ
削除していいですかっていちいちDBに聞くのか？

クエリを
「したいんだけどどうよ？」
という問い合わせに読み替えなさい。

>>62
なんかいいね、それ

9iダウンロード中

でけぇ・・・あと６時間かよ

フッ おれもアナログ回線だからダウンロード大変さ
>>57
なるほど。
でもフィールド名につけたい英語って予約語が多い[YO]

>64-65
9iで勉強するとして、Oracleの入門書って何がいい？

入門書ってロクなのないからそれなりに分厚い本買っとけ

ぶ、分厚いのと言われても…。

つか、Googleとかで「Oracle 入門書」で調べればいいのか。

逝ってきます。

>>64
DBマガジン買ったら？
今月辺りCD-ROM付いてくるのでは．．．

オラクル系、元気すね。
勉強進んだら教えてください。
>>60
えーと、テーブルが1つで、「書き込み」
フィールド：書き込み番号、名前、E-mail、書き込み、書き込み時間

ってとこでしょうか。名前やE-mailがちゃんと機能していれば、
書き込み人のテーブルを作りたいところですが、現状では、
「仕様書無しさん」「sage」ばかりで、同一人物の特定もできないので。
60さんの考えを教えてください。

>>70は俺です。名前忘れた。

日記：
だんだんきつくなる。
今日はVBAだと思ったら、マクロはもっと簡単だった。
自作のフォーム上にボタンを貼って、そのボタンでフォームを閉じるようにした。

やり方：
フォームをデザインビューで開き、ツールボックスからドラッグアンド
ドロップでボタンを貼り、コマンドボタンウイザードをキャンセルして閉じ、
ボタンを右クリックして、プロパティを開き、イベントタブの「クリック時」を
クリックし、右横の3点ボタンをクリックして、マクロビルダを立ち上げる。
マクロに適当な名前を付け、アクションで「閉じる」を選択。
オブジェクトの種類をフォームとし、オブジェクト名を閉じたいフォームの
名前にする。あとは保存するだけ。

あるいは、はじめに、データベースウインドウで「マクロ」を選び、同様の
操作でマクロをあらかじめ作っておくと、フォームにボタンを貼り付けた
ときに、コマンドボタンウイザードでそのマクロが選択できるようだ。

ちょっとおもしろい。
お客をちょっと喜ばせるものなら、（勉強すれば）作れそう。
明日はモジュール、今度こそVBAだろう。

>>53
オラクルならこんな感じになるぞ。
SELECT 社員名簿.社員番号, 社員名簿.氏名
FROM 社員名簿,給料表
WHERE 社員名簿.社員番号 = 給料表.社員番号;

ありゃ、Oracle って日本語ＯＫだっけ？
8iぐらいから日本語サポートがコッソリ消えたような気がするけど。

>>69
本屋が開いてる時間に帰れねぇ〜んだよ！（涙）

9iの方は朝起きたらルータがハングって止まってたけど、
昼間に落としたら２時間ぐらいで落ちた。

さて、どうすっぺ。

ビューを使えば日本語はいけたはずだよ。
テーブルのカラム名に日本語名は８以降つけたこと
ないからわからんが。

>>74
御勤め御苦労さん。
http://www.seshop.com/
でバックナンバーも含めて購入できるらしい。
会社に届けてもらったら？

>>76
あ、落とせたのか。
勉強がんばれよ。

今日は飲んでしまいました。
それで、明日はちょっと客先へ。
うー、VBA拒否症か。限界か。
すんまへん。

>>78
負けるな！
そこを乗り越えてアレルギーがとれたら道は開けてくるぞ。

・・6日で音信不通になりやがったか。(w

もう少し保って欲しかったもんだがな。
理解して音信不通になるならまだしも、
拒否症とか書いてるし。

>>80
確かに弱えな。戦闘力6キリってところか。
こういう奴は何やっても駄目だろうな。逝け。

6日に賭けた人、いる?

>>75
日本語、いけるはずだよ。

まぁ、ＤＢの勉強と言いながら VBA に言ったのはちょっと
方向性は違うかなと言う気がしたが。

ＤＢ勉強の方針案。
１）ＤＢの基本概念
２）ＳＱＬの基礎
３）ＤＢ構築
４）ＳＱＬ実習

てなところかな、最初は。

オラクルマスター銀っぽいね。

オラクルマスター銀とれないって。(w

銀は問題集を丸暗記すれば取れるんで、あんまし
役に立たないかと。

役には立たないが、
「これくらいは分かってるんだよな一応」
という指針にはなるよ。

銀のオラマスを3枚集めると何がもらえるんですか?

３枚でOracleの缶詰がもらえるよ。

表名、列名の日本語問題ないです。
それ以外のオブジェクトも問題ないとおもた。

オラクル禁の問題集立ち読みして、十分いけそうなんで受験料
調べたんだが、アホらしくなった（ｗ

でも受けようかなぁ。ちっと迷い中

Ｍ＄とOracleの資格は金で買うものだ

>>89
金のオラマスを買う権利が与えられます。

銀は5枚ぢゃなかったか？？

あなたが落としたのは金のオラマスですか？
それとも（以下略

>>95
いいえ、国家公務員資格です・・・

ご無沙汰しました。
最初は、厳しく叱責され、しだいに忘れらた1です。
ちょっと挫折してましたが、今日、古いVBの参考書を引っぱり出して、
まねしながら、AccessのVBAをいじってみました。
わかれば難しくないようですね。

日記：
Accessの本には、VBAの簡単なサンプルがあったので、まねしてみた。
難しくはない。
VBAの練習はすぐ終わって、次はSQLの話になってる。

　VBAのお稽古：
　フォームを作り、ラベルを貼る。キャプションを適当に入力。
　右クリックでプロパティを選び、「その他」で名前をlabel1にする。
　ボタンを貼り、ウイザードはキャンセル。
　右クリックでプロパティを選び、名前をButton1にする。
　続いて、「イベント」で「クリック時」を選び、
　「イベントプロシージャ（かな？）」を選び、横の3点ボタンを押すと
　プロシージャのコードを入力する場面に移る。そこで、

Private Sub Button1_Click()
label1.Caption = "Hello, VBA"
End Sub

　と入力する。
　あとは、VBを閉じ、Accessの場面でフォームを保存し、実行。
　ボタンを押すと、ラベルに「Hello, VBA」と表示される。

1のキャラ、ﾁｮﾄいいな｡
↑思わず笑っちまったい｡
前回から引き続いて､DBの勉強からずいぶん遠いところに来ちゃってるな｡
Cやってんなら、もっと別な選択肢がありそうな気もするが｡
まあそれも1のキャラ､てことか｡
半分ネタスレだがまあ許そう｡
万が一、本気なら､ビジネスソフト版のAc相談所のほうがふさわしいが､
何かほのぼのしていい感じだから、ここで続けろ｡

>>1
VBAよりかはＳＱＬビューを見ていろいろいじってみるほうがいいと
思うがどうよ？

うむ。
実のところ、>>1 はＤＢよりＶＢＡを勉強したいのでは無いかと思わせる。

あまり迷わせるような事は書きたくないんだけどね。

結局 >>1 はなにを勉強したいのだろう

DBの解説をすると見せかけてじつはVBAやADOの解説をしちゃってるなんちゃってDB本によくあることだな。

プログラマの職につくつもりは全くないのですが、
データベースくらいは教養として知っておくべきなのでしょうか？

>104
一般ユーザなら、Accessをチョロチョロ触れるくらいで十分。
もちろん、余裕があるならどんどん覚えちゃっていい。

>>99
ありがと。俺はネタじゃないんすけどね。
DBから離れていく．．．。確かに。
>>100
SQLはSQLで勉強します。
>>101
いえ、そうじゃないんです。
>>102
DB一般す。

えーと、俺はほんとにDBを勉強したいんです。
Accessがよく批判されているのも知ってます。
でも、批判してる人はAccessを理解しているわけですよね。
「あのSQLはおかしい」とか言えるのも、知っていればこそ。
ということで、Accessも勉強したいんす。
そうと決まれば、あんまり好きじゃないGUI操作やVBAも
やっちまわんと、ということなんです。
やってみたら、ちょっとおもしろかったんですけど。
（VBAとSQLが混ぜられるなら、それはおもしろそう。
ほんとは、Java+SQLに行きたいけど。）

あんまり自分の話をするのは好きじゃないです。
恥ずかしいので、他に勉強してる人も経歴や目標でも
書いてくだされ。

日記：
今日はいきなりSQLだった。ちょっと順番がよくわからんけど。
SQL：データベースと会話する言語らしい
SELECT句：データの検索（これはわかりやすい）
INSERT句：データの挿入
UPDATE句：データの更新
DELETE句：データの削除

明日はテーブルハンドリングって、DAOとかADOの話らしい。
一日じゃ無理だっぺ。
眠い。ただひたすら眠い。

教養ときたか。
だったら東海道五十三次全部いえる奴のほうがえらいぞ。
中山道までいえれば神だ

>>108
中山道だけなら言えるってのは？
なにしろ滋賀県出身なので・・・。

>>108
なんか教養の意味をはき違えてないか？

日本橋、品川、川崎、神奈川…までしか思いつかなかった

何かここ、どんどん良スレになっていくな。
俺、こーゆーの好きよ。
1の人徳に、ｶﾝﾊﾟｲｰ

>>110
「>>1よ、東海道・中山道をDB化せよ」という意味と思われ。

>>106, 107

まず、DBあるいはRDBって何のためにあるのか考えるのが
いいと思う。

たとえば、なんでExcelだとだめなのか、とか。
（念のため言っておくと Excel がだめなソフトだとはいってない。
Excel にかわって Oracle や SQL-Server を使わなきゃいけない
場面があるってこと。）

確かにRDBを使えるってことは、SQLを知っているということと
同じような意味にはなるけど、でも、その前に考えなきゃ
いけないこともあるぞ。

>たとえば、なんでExcelだとだめなのか、とか。
この業界、逆にEXCELの方がいいだろってところにも
高ーいORACLEを導入しちゃったりするね。
ISAMで十分でないのという案件を何度も見たことがある。

Accessやるなら。
クエリーと、画面上のテキストボックスなど入力欄の連携ができねーとつまらんよな。
そーじゃねーと、何のためのGUIなんだか、ってことになっちまう。

ブランド志向が強いからな・・・

ShadeよりLW　LWよりSoftimage

高ければ良いって物じゃないんだけど

>>107
ＳＱＬって一日で終わったのか…。

>>107
勉強がんばれよ。

でも、DBやりたいのなら試しに何らかのもの
例えば小遣帳でも作るという目標でも立てて
DB構築→GUI→VBA等のコーディングと
進むのが良いかと思うが？

DB系システムの場合データベースが重要なのであってGUIやプログラムは
あくまでデータを間違いなく入力し、出力するための手段だという事を忘れんでな。
(別の人も書いているが手段が目的化している参考書も結構多いんで．．．)

他に適切なスレなくて横割りになって悪いけど、
カラムが400とか500のテーブルって設計的にどうよ？

>>120
逝って良し、だ。

>>120
オラクルだったら行連鎖ほぼ確定コースだね。

>>120
どんなデータが入ってるんだろ？第二正規化もしてないとか？

1が戻ってきてる…ｴﾗｲ!
ﾏﾀｰﾘ ｶﾞﾝﾊﾞﾚ

>>120
設計っつーか…ご愁傷様。

>>114
わかりました。考えてみます。
>>116
現在、一番知りたいことは、その辺なんです。
>>118
いえ、教科書読んでるだけで、それぞれ例が1つだったんすよ。
>>119
まったくおっしゃる通りだと思います。

ちょっと身元バレが怖いのでちゃんとは言えないんすが、
仲良しのお客さんのところで「テーブル１つ＋フォーム1つ」のDBを
作って遊んでもらってます。
でも、検索とか簡単にできなくて、怒られちゃいました。
（真性プロの方は激怒するかもしれませんが、俺の商売そんなもんす。）

>>124
ありがと。がんばるっす。

それで、みなさん、いえ、みなさま。今日は何もやってないです。
むかーし買ったデイトって人の「標準SQL第2版」ってのを見つけだして、
読もうと思って寝ました。

ネタとしてお勧めなのは、ToDoとかメモとかスケジュールとかをRDBに入れて
実際に自分で使ってみることかなぁ。

ヲレは上記の三つをPostgreSQLとPHPで作って俺Webアプリとして使ってる。
もう一年くらい友達も一緒に使ってる。

やっぱ自分で使うものを作ってみると思いつくこととかもいろいろあっていいと思う。

>>125
いい商売というべきか？給料安そうだが。
ていうか、学生さんの便茶？

漏れはDB厨なんだけど正規化ってのをすればテーブルに格納するカラムがうまく分割できるのでしょうか？

ちなみにテーブルの中身はなぜか月単位での顧客情報（なぜか名前など含めて）です。
素人判断でアレなんですけど、普通は月単位で必要なデータと
名前や住所などのようにあまり変更のないデータは顧客Noかなんかでリレーションを
張れるのでは？　って思ってますが、実際どんな感じなのでしょうか？

>>128
そのとおり。

>>128
そのまま使ってると他のテーブルにも顧客情報がすべて入るはめになる。
それを避けるために正規化をしなさい。

回答どうもです。

と、いうことは正規化すると複数のテーブルにキー項目以外で
重複カラムが存在しなくなって、情報も整理されると考えられるんでしょうか？
ちょっとその辺り（正規化）の本を物色してみます。

>>131
　だーかーらー、「あるデータはただ一ヶ所にしかないようにする（重複の排除）」ってのは、
もっとも基本的な正規化なんだってば……

　とりあえずセルコー師の本を読むのがよいと思われるが如何に＞諸兄

>>132
>セルコー師
もちっと正確に教えてください。

スマソ。まだまだDB厨なので、正規化については全然知らないのです。
セルコーでググール逝ってきます。

>>134
ちょっと例をあげよう。
月単位のデータを持ってるテーブルに
顧客情報（氏名等含み）があるとする。
日単位でデータを持ってるテーブルにこれまた
顧客情報（氏名等含み）があるとする。

月単位のテーブルと日単位のテーブルで同じ顧客情報がたくさんあるとする。
そうするとだなこれを顧客情報のテーブルを作る。
そして顧客情報は顧客情報のテーブルにすべていれる。
そのとき適当に顧客NOをふる。
で、月単位のテーブルと日単位のテーブルに同じNOをいれておく。
そうするとすっきりするだろ。
そういうことだ。

列名および表名に日本語つけるのヤメレ
悪いこと言わないからヤメレ

それと列名をまんま付けるとホノニムだらけになるぞ

台帳:データには日本語がいっぱい入っている
履歴:データには数字とアルファベットしか入っていない

こんなんじゃダメか?
いや、ダメならダメといってくれ。

>>133,134

題名はこれ
「プログラマのための SQL 第2版」
Ｊ・セルコー著
ピアソン・エデュケーション
\4,500-

正規化について詳しく順を追って解説してあるし、SQL の構文についてもかなり
詳しくかつ突っ込んだ解説がある。
SQL のバイブルだと漏れは思ってるよ。

「プログラマのためのSQL」は、既にある程度SQLの勉強をした人
が、更なる高みへと進むための本、て感じだね。
いい本だが、少し難解でもある。

「SQLパズル」もあるでよ

Accessやってるならいいものがある。
「SQLがわかる本」
芝野耕司著
オーム出版局
ISBN4-274-07872-8　1400円
Accessを例題にしてSQL全般について語っている。
分量などは覚えたものにとって不足だろうが、入門としてはいいと思う。

SQLってどの位出来れば、出来るって言っていいの？
group by、having、副問い合わせが書ける程度でOK？

>142
自分が出来る事、出来ない事を説明できるレベルかな。

クライアント側のプログラムでDBに問い合わせるのはできます。
ストアドは書けません、とか。

Access、VBだと、「谷尻かおり」の本が好きだ。
あれにはお世話になった。
特に「ACCESS97<実践>クエリー入門」には助けられたっけか。

SQLって、エンドユーザがＤＢに対して簡単に問い合わせできる
ように・・・って言うツールだと思ってたのだけどねぇ。

いつの間にか開発者言語になっちゃったのかな？
SQLが難しくなりすぎた？
ユーザが贅沢になった？

うーん。でも、プログラマには初級のＳＱＬ
で悩んで欲しくないな。

>>143
それはＳＱＬに限らずどの言語でもいえる話しでは？

>146
同意。
例えば、きちんとパソコンを使える人は「パソコンを使えます」なんて言わない。

>>147
ちょっと前まで履歴書で「趣味：インターネット」と書けたのと同じノリだな

>145
　本来の生い立ちは、そういうコンセプトで作られたものだったと思う。
エンドユーザーが自然言語に近い形で、云々ってのを見た記憶があるんだが。
開発言語ってほど贅沢なことはできんけど、ストアドあたりで自分は悩んだ記憶あり。

>144
　谷尻かおりの本は中々良い。Ac2000のVBA本、技術評論社のやつ持ってるんだけど、
ちゃんとADO、DAOの比較までやってくれてたり、SQLにもページ割いてくれてたりして、
助かるよ。今でもたまに引っ張り出して見たりしている。

　>1　は期待してたのに音信不通か？Accessだったらアドバイスくらいやってやるんだが。

ちゃんと休暇申請出してから休めよ(笑)＞1

>138
セルコー買ってきました。
まだ一度しか読んでないのですが、不要な（というか、独立性の高いデータ？）カラムの排除については
解りましたが、他はサパーリでした。繰り返し学習します。

すんません。休んでます。（仕事してます。）
そのうち必ず復帰します。

保全age

勉強人Mはどこへ行った？

>154
休暇申請がでてるため休み

晒す

休むなよｺﾞﾙｧ!!>>1

休みsage

休みは終わりだｺﾞﾙｧ!!>>1

最初に書いた本を読んできたのですが、ADO、DAOとかになったんす。
で、だーいたいの意味はわかる（というか知っていた）んですが、
具体的な手順がぜんぜんわからんのです。本にはダイアログでの
設定とかもっともらしく書いてあるのですが、どうやってその
ダイアログを開くんだか、何なんだか。
ここで死んでました。すみまっせんっ。

で、これは飛ばして、具体的なサンプル制作に入ろうかと思ってます。
泣き泣きです。

だからさ。
ただ本読むんじゃなくて、実際に書いてあるﾂｰﾙなりなんなりを動かしてみれ？

そうすりゃ何のダイアログなんだか解るだろ。

>161
同意。
結局本を見ててもなんの勉強にもならん。
がんばれよ >1

勉強人X挫折しかけage

>>160
直接関係無くてスマン。

ACCESSのVBA関係のヘルプは全て入っているの？
確かデフォルトの設定だとそういった開発系のものって入らなかったような．．．

こっちは桜がチラホラ咲いてきた。
散ってしまうまでに完成すると良いな。がんばれよ。

>具体的なサンプル制作に入ろうかと
サンプル作る時ははじめから大きい物を作ろうと思うなよ。
小さいくてもいいから必ず「完成」させる事。コレ重要。

>小さいくてもいいから必ず「完成」させる事。コレ重要。
サンプル作るときはいろんなことを試しながら作ること。
コレ重要。

　基本は手抜き。根性コーディングに走るとタチ悪い。
ADOとADOXのオブジェクト群一通りくらい覚えれ。

春の試験、受ける人いる？

質問です（このスレでいいかな）
varcharとchar使い分けてるか？
個人的には固定長であるはずなのに後ろスペース入れるヤツがあったり
して紛らわしいだよ！おれがテーブル設計するとき全部varcharにしたら
文句いわれた・・どーでしょう？

あたりまえだ。
いっそのこと全部VARCHAR2でやった方が効率がよい特殊なDBを除いて、
きちんと使い分けろ。

つーか、VARCHAR使ってるやつは見たことない。
VARCHAR2とかじゃねえの？

VARCHAR2とCHARは使い分けるときがある。
が、一度VARCHAR2(1)はCHARで設計しろｺﾞﾙｧ！！って怒られたことあり。
なめんなよｺﾞﾙｧ！！って心の中で叫びながら、満面の笑みをうかべて
「嫌です」って言ってた記憶あり

はっきり言っておまえにテーブルレイアウト設計させるのは2年早い。

しっかりしたDBAの設計に1年触れて、
しっかりしたDBAの元で1年修行しろ。

はっきり言っておまえにテーブルレイアウト設計させるのは2年早い。

独学マンセー

一回イチからきっちりとテーブルの容量見積もりやってみろよ。
そしたら使い分けの重要性がわかるからさ。

DBよろず質問ってここでいーですか？

UPSERT文の構文について教えて下さい。
検索したけど見つからないの・・

VARCHAR2(1)とCHARの使い分けは重要とは思えないが
一応Oracleプラチナ
こんなおいらは逝ってよしですか？

ＵＰＤＡＴＥとＩＮＳＥＲＴなら聞いた事有るが……。
俺って逝って良し？

>>175
　Oracle 9i の新構文だっけ？　OTN Japan でマニュアル PDF ダウンロードしてこい。

>>176
　名前から類推できるとおり、「Update してみて、できないときは Insert する」を一文
で書けるという代物であったと思う。
　確かにあると便利ではある。

＞178
うお。
そりゃ便利だなおい。

create or replace とかと言い、oracle ってそいうの好きやなぁ。

bag を大量生産しそうで怖い・・

ソースが短くなりそうで、たしかに便利そう。
ＩＳＯに採用されたらつかってやる。

アップサートはオラクルじゃマージ文だよ

>>177
俺もプラチナだがそんなにこだわる必要性がわからん。
NULL項目が極端に多ければ別だが。。。。
NOT NULLが多ければ全部Varchar2にして良いと思うぞ。

VARCHAR2(1)とCHAR(1)ではSGAで使用するメモリ量が違うので
突き詰めていくとやっぱCHARにしろといってみるテスト。

でもおまいらのクソ業務はどっちでもいいよ。

日付はdateですかvarchar2(8)のどっちですか？
date型は変換がつきまとって面倒だよ、だいたい実際は日付関数を使うより
日付の＝、範囲を問合せる処理がほとんどでしょ？だったらvarchar2(8)
つかいませんか？

UPDATE分とINSERT分のフォーマット違いすぎるの
なんとかならんもんか
えくせるのデータからSQL自動生成するときめんどくさい

規格できまっちまってるもんは仕方ないだろう。
VBAつかえよ。

>>184
そのメモリ量とVARCHAR2の扱いやすさのどっちを取るかってやつだと思うが
メモリの細かいところは結構どうでもいいとおもったりする。

>>185
DATEにしとけ。時分秒も管理できるぞ。
大体CHARにしたって変換の手間がかかるのは一緒だ。

時間演算系の関数は使わないのか？

>>185
日付ならせめて VARCHAR じゃなくて CHAR だろというツッコミは置いといて、
日付型使うほうが面倒少ないぞ？

というか、「ある日付からｎ日前までを取得」とか、日付型なら SQL だけでいけるだろ。
文字列にしちまったら、プログラム側で文字列の日付を計算する処理しなきゃならな
くて無駄だと思うんだが。

そもそも日付を CHAR でやるのは COBOLER の癖であって以下略。

>>190
> 「ある日付からｎ日前までを取得」とか、日付型なら SQL だけでいけるだろ。
　select to_char('YYYYMMDD', to_date('YYYYMMDD', '20020301')-4) from dual;
でいけるんでない? まぁ、美しいとは言わないけれど。

漏れの部署は、全部 char か varchar2。integer も date もない。
最初、すげードキュソ DB だなぁって思ったけど、最近考え変わった。

ブラウザ→web サーバって、結局文字列しか渡せないでしょ。
だから web アプリ作るのなら全部文字列で取っておくのも悪くないかな、と。

例えば、DB と Bean のマッピング表を作って、SELECT 時の
DB→Bean 処理も、INSERT 時の Bean→DB 処理も、全部マッピング
表に従って一元管理するようにしたのね。そしたら DB は全部文字型だって
わかってるわけだからとても楽だった。

他の人の意見が聞きたいんだけど、これどう思う?

date型にしておくと、時分秒まで入れちまうヤツが居るから・・・
最小値と最大値の限界もあるし

DATE型の方がSGAのメモリを多く使うからどっちかというと
CHARも捨てたもんではないと逝ってみるテスト。

もちろんTO_CHAR/TO_DATE多用。

timestampが必要な場合以外はCHARというのもアリよ。
HDDの領域ケチるついでにレコードサイズ縮小を期待してもヨイ。

>>191
確かにいけるが、なんつーか、
・重油を炊いて熱を得て
・その熱で蒸気を作って
・蒸気でタービン回して発電して
・その電気でモーター回す
みたいなもどかしさを感じるのだが（ｗ

ただ、Web がらみで入力が文字列に限定されるからというのは理解できる。

うん。欲しい情報が年月日だけだったらCHAR固定のがいいでしょ。
SYSDATEとか時分秒まで欲しいのは_DATE、CHAR型のは_YMDって名前で区別してる。

日付をchar系で設計するのは汎用系やdate型の便利性を知らないヤツと
思われてるみたいですが・・
where xx_ymd = '20020322'
where xx_ymd = to_date('yyyy/mm/dd')
では上の方がスッキリするのでcharを使ってます

話を戻すみたいで恐縮しつつ、
うちの部署は固定長の年月から1バイトの区分まで全部VARCHAR2です。
たまにスクリプト間違っててNUMBER型になってても
「既存はもう動いちゃってるから・・・」と言ってほったらかしです（ｗ

>196
date型ってwhere xx_ymd = '2002/03/22'って書けなかったっけ？

196ではありませんが…

>>197
> date型ってwhere xx_ymd = '2002/03/22'って書けなかったっけ？

少なくともOracleでは書けます。Oracleではこの場合文字列をデフォルトの日
付書式にに従って変換するので明示的に書式を指定してto_dateで変換するの
であれば意味はあるでしょう。

なんというか扱いたいのは日付であって8桁の数字ではないんですから、素直
に日付を表す型であるdate型を使えばいいと思うんですけどね。

日付にdate型ではなく文字列型を使いたがる人達って抽象的な思考が出来ない
傾向にあるように思います。目に見えない日付というデータではなく目に見え
る8桁だか6桁だかの数字の方が安心するというか。

この調子だと多分1万年問題の時も大騒ぎになるんでしょうね。ま、自分には
関係ありませんけど。

>>198
凄まじいﾈﾀだな。
さすがにあと八千年はもたんだろ。(w

Oracle 2023zとかになってるのかな（ｗ

>201
さすがにその頃までにはDML,DDLに空行入れてもまともに動くようになってるだろう（ｗ

その前にDATE型だと2037年問題があるだろ。
大丈夫っつってても絶対信用ならねー

>202

2038年じゃなかったっけ?。まぁそれはともかく。

問題になるかどうかは処理系によるのでは?。Oracle8ではDATE型の内部構造は
確か年月日時分秒に1byte(8bit)づつを使っていたと思うのでtime_tの32bit問
題とは関係ないはず。計算の途中でtime_tを使っている可能性はありますが。

以前はtime_tを使っていたんでしたっけ。それで文字列よりも比較が速いから
DATE型を使うべし、という意見も聞いた事があります。

言いたいのは、DATE型を使っておけばそういう実装の事を気にしなくていいと
いう事。抽象化ってのはそういう事です。

どんな内部構造でもそれ固有の制限はありますが、DATE型を使っておけば処理
系の中に閉じ込める事ができます。

もちろん、処理系が対応するかというリスクはありますし。処理系の移行に伴
う問題もあります。

>199,200

2000年問題を仕込んだ人達も同じ事を考えていたんでしょうねぇ。

「2000年を過ぎたんだからうるう年は4年に一度でオッケー」とか言っている
人もいましたから、2100年問題もあるんでしょうねぇ。これまた自分には関係
ありませんが。

2038 年までには time_t (unsigned long) は 64bit なので
ノープログラム。

>>203
俺は Date型使うけど。
で、考え方には概ね同意なんだが。
要は、2038年問題が起きようが、RDBMSを取り替えれば良くて、
システムはそのままで稼働可能、つーことだろ。
# 本当に動くかどうかはしらねぇがな。


> 2000年問題を仕込んだ人達も同じ事を考えていたんでしょうねぇ。
これの問題は数十年のオーダーだろ。
確かにそれは問題になることが証明されたわけだ。

だが…。
8000年もの期間、稼働し続けられるハードがあるのか？
例えパーツ交換を行い続けたとしても、もはや考えるべき範囲を超えてる。
そもそも、タイムオーダーが違いすぎるだろうが。(w

>>205

> 8000年もの期間、稼働し続けられるハードがあるのか？

いや、今使っているハードはソフトがそのまま動くなんて思っている訳ではな
くて、日付を(その為に用意された抽象型ではなく)文字列で扱うという習慣は
いつまでたってもなくならないだろうなぁ、という事です。

2000年問題だってNECの携帯でも発生していた位ですから古いハード/ソフトだ
けの問題ではありませんでした。

そういえば、1999年頃にちょっと関わっていたシステムでも「50以下/未満で
1900年代を2000年代を区別するから年は2桁で扱う」という事をやっていまし
た。日付別のソートはどうするんだ、と質問しても回答は得られませんでした。
多分クライアント開発者に泣いてもらったんでしょうけど。

一番大きいのはだね、きみたち、
西暦をいつまで我々が使い続けるのか、という問題なのだよ。

DATE型ならDBMSがなんとかしるだろうが、
文字列で持ってたらね、つまりね、アプリ内部でなんとかしる必要があるんだよ。

これからはね、和暦よ、和暦。
DBMSもPC/WSも性能上がってるからね、和暦で持つのが一番。
でもてんのーへいかが１００年以上在位してるとやばいからね、
和暦+三桁表記。
これよ。

和暦も昔は三文字とかあったからね、こっちも多少余裕を持たせて
漢字4文字+三桁表記。

あとはね、てんのーせいをね、守り続ければいいの。
キリストキョーがホロンデモね、和暦を守ればいいの。

これよ。

もちろん、JISでね、DBMSの規格を制定してね、
TO_WAREKIとか
TO_CHARで和暦サポートは当たり前。

和暦で演算だってしちゃうのだよ。

和暦はね、文化よ。
企業の利益もいいけどね、文化をね、壊さず守るのがわれわれ情報産業に
携わる人間の本当の使命なんだよ。

>>206
> 2000年問題だってNECの携帯でも発生していた
あれは NEC が莫迦だってだけ

charかvarcharを選択する場合、設計時に将来そのコードは不変で固定長で
あるか？の討議になれば議論は終結しません。
なんせ客の一言で数字に文字ありにしろなんて事はザラです
設計者の私的な意見でdate,number,charを設計するのは危険です、そこらへんを
いい加減にvarcharで設計する手法は邪道なんでしょうか？

少なくともMSのはなんか出るだろうね>2038年
2000年の時もあんだけ大丈夫って言っておいてパッチ出まくりだったんだから・・

DATE型だと、日付しか必要ない時も時分秒が勝手に設定されるのがイヤン。
SELECT リリース日→2002-03-26 00:00:00
夜中かいっ！ て感じ？

手抜きしないでTO_CHARしる。

>207,208

そういえば昭和100年問題というのもありましたねぇ。

> TO_CHARで和暦サポートは当たり前。

知ってて書いているのかもしれませんが、Oracleでは今でもサポートしてます。

他のDBMSは知りませんが、官公庁で採用してもらおうと思えば元号をサポート
しない訳にもいかないでしょうから商用DBMSなら大抵はサポートしているんじゃ
ないでしょうか。

それでもそんなものを使わずにcharで和暦を持つから昭和100年問題なんても
のを心配する事になるんですが。

>>214

JISで制定することに意義がある。
Oracleがやってるのは、しってる。

日本人なら皇紀使え

>>211
Oracleもなんだかんだ言って2000年関連のパッチいっぱい出てたよ。当時の現行バージョンで。
まぁメーカーの「対応済み」なんてあてにならんってこった。

ＤＢってもちろんドラゴンボールだよな？
�Vとか�Wとか出たらまた連絡してくれ

勉強人X復活期待age

私もＤＢを勉強し始めたものです。

コマンドでデータベースを作るのが面白くて、
mysqlをちょこっとやっています。

お、がんばれ！
プラットフォームは何？

cloudscapeであそんでます。warに固めれるんで便利便利

>218
オラ達ならはそんぐれぇは気で探れるぞ。

>>221
がううう。

Oracle 9i Datebase fror Windowsという本を買いました。
これは体験版のＣＤがついていて、
インストのやり方が書いてあります。

きちんとインストしたはずなのにぃ。
インスト失敗。データベース起動せず。
黄色信号なのですよ...

でもって、仕方なく、mysqlをＤＬしてきて、
sqlの勉強。

WinNT/2K使ってるか？
9x系で開発の勉強しようなんてエイプリルフールの冗談にしては
おかしすぎる。

>>225

がうう
Win2000です。

SQLはこのページ勉強してます。
http://www.rfs.co.jp/sitebuilder/sql/
他にオススメのサイトがあったら教えてください＜（＿ ＿）＞


やっぱり、勉強用でも、オラクルはまっさらなＯＳに
インストするのが基本みたいですね。

MS Officeとか混在した環境で使っている人はいますか？

＞ＤＢってもちろんドラゴンボールだよな？
>>218
ちがうよ、最近のはダークブリンクって言うらしいぞ。
レイヴってマガジンに載っているらしい。

>>226
http://homepage2.nifty.com/sak/

色々揃ってるし、リファレンスにはちょうど良いよ。

未だ復帰しないのか？

勉強人Ｘではありませんが、レス失礼します。アクセスを触り始めて２ヶ月
経ったくらいです。社員は私も含め全員ワードとエクセルしか使えない事務
系の職場で働いています。予算や決算のため年度の集計をすることが多い
今日この頃ですが、職場で使っている表には「々」とか「〃」とかがたくさん
入力されていて合計計算も並べ替えもできない状況です。今のところカット
＆コピーで並べ替えたあと印刷した表を電卓で計算して集計しています。
先輩に「セルには必ず数字を入れるようにしてはどうでしょうか」とお伺いを
しましたが「そんなことしたら見にくいでしょ。勝手なこと言わないで」と
言われてしまいました。
そこで、アクセスのフォームを使えばフィールドには必ずデータが入るよう
にできるのでは、と思い参考書を見ながらエクセルの表と同じものをアクセス
で作りつつあります。始めは変な目で見られましたが、入力フォームだけは
市販ソフトのように綺麗にして、フィールドへの入力はクエリーから既定値を
引っ張ってきたりコンボボックスから選ぶようにしたりしたところ最近では
先輩も私が作ったアクセスのファイルを使ってくれるようになりました。
前フリが長くなってしまいましたが、よろしければ教えていただきたいことが
あります。というのはテーブルの作り方です。始めは単にエクセルの表をアク
セスにインポートしただけでテーブルは１つしかありませんでしたが、だんだん
都道府県名のテーブル、支店名のテーブル、入出金のテーブル等に分けてリレ
ーションを結ぶようになりました。参考書にはそうしたほうがよいと書いて
あったもので。しかし、最近では数字だけのテーブルとかがたくさんできて
自分で見てもテーブルごとの関係が把握できなくなってきました。テーブルを
分けすぎているのではないかと思います。異なるテーブルに同じデータを書く
のはまずいといいますが、どの程度なら重複するデータを作ってもよいので
しょうか？やはり、まったく重複してはだめなのでしょうか？テーブルの
分け方について基準があればぜひアドバイスお願いします。
ずいぶん長文になってしまいました。ごめんなさい。

>>230

非常に見づらい、やり直し。

もっと簡潔に

>>231
今流行ってる斜め読みを知らないのか？

>230
ヒント
テーブルの正規化

俺はAccess使ったこと無いからよくわからないんだが
テーブル正規化ウィザード
つうツールがあるのね。

>>232

ほほう。　　そういう事か

>>234
どういうことか小一時間教えてﾎｽｨ。
ネタなのに。

>>230
商売物で無いのなら明確な基準など存在しないと言って良い。
自分にとって都合の良い設計が最も優れた設計と考えて間違いないと思う。
でも将来、他の人に引き継ぐ可能性が有るのなら、その参考書で述べている
事に従うべきだ。
冗長な構造のDBは君の文章のように他人には理解しづらいからだ。

>>235
＞ネタなのに。

　　↑と、言ってるおまえがネタなのか？　ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

＞２３３
「テーブルの正規化」やってみます。
ツールがあるのは知ってましたが、どうなるかわからなかったので
怖くて使えなかったのです。まず、バックアップファイルで試します。

２３０は自分でも読みにくいです。ダイエット心がけます。

ありがとうございました。

>238
俺はそのツールは何が起こるか知らないからな。
名前がそれっぽいってだけだ。

先ずはお前の文章を正規化することからはじめろ。

似たような名前を一緒にするかどうか聞いてくるので
いちいち「やるなバカ」と指示を出さなきゃ逝けないウィザードだが、
余りよく分かってない人間にいじらすのはどうかと思う。

正規化試してみました。
重複データの多いフィールドを別テーブルに分けるだけのようです。
私が今やりたいこととは違いました。
３２６さんのご忠告はもっともだと思いますので、
構造を見直し、イチから作り直すことにします。

>>242
×　326
○　236

ワシはＷｉｎｄｏｗｓ３．１の時代のＡｃｃｅｓｓ使って勉強しとるよ。
窓を閉じるボタンがＭａｃみたいに左上隅にあるよ。
ＳＱＬビューが（ざっとみた限り）無いので、その辺の勉強は
ＰｏｓｔｇｒｅＳＱＬでしとる。

あ、あがってますね。
一応、Accessで、ちょろ〜いDB作れるようになりました。
これからODBC-JDBCブリッジでもやろうかと思っています。

途中退場してすみませんでした。
なんかとても高度な話題が出てきたので、なんとなくROMになっちゃったんです。

どの辺が高度な話題なの。
と聞いてみるテスト。

「正規化」あたりとか？（w

その後勉強進んだか？

古いスレ上げてきたな･･･

ごめんなさい。もう見捨てられたかと、報告なしでした。

お客さんに出したおもちゃのDB（Access）は一応、重大な問題を起こさず稼働しています。
不思議なことに、「レコードの順番がめちゃくちゃになってしまい直せない」ってことがありましたが、
データをコピーしてソートして作り直しました。
それから、主キーをオートにしているのですが、どういうわけか、お客さんが空のレコードを
削除してしまい、番号が飛んでしまうということもありました。これもコピーしたりして直しました。

以上より思ったことは、「Accessを直接使わせてはいけない」ということです。
それで、>>245に書いたように、ODBC-JDBCブリッジを勉強しています。
独自アプリを書いてみたい（書いた方がよい？）のです。
社長もわかってるんだかわかってないんだか、なんですが、ゴーサインが出てます。

あと、ゆくゆくはイントラで、WEB連携にしたいと思ってますが、サーブレットとかXML
とか、わけわかりません。

俺、やっぱりPGにあこがれたんす。

>不思議なことに、「レコードの順番がめちゃくちゃになってしまい直せない」ってことがありましたが、
>データをコピーしてソートして作り直しました。

主キーをオートのランダムに設定してたのでは？ランダムの場合、レコードの順番は挿入時とは
まったく異なりますよ。

>それから、主キーをオートにしているのですが、どういうわけか、お客さんが空のレコードを
>削除してしまい、番号が飛んでしまうということもありました。これもコピーしたりして直しました。

オートのインクリメントの場合はレコードを削除して使われなくなった主キーが発生しても
その主キーが再び使われることはありません。暗のうちにその主キーにリンクしている
レコードがあるかもしれませんからね。これはAccessに限らず全てのRDBMSにおいて
いえることです。

知っていれば当然だが、そうでないとハマりやすいポイントだな。
誰もが通る道だと思う。けっこう良い経験しているんじゃないか？

そんなもの、で済まさず、何故そうなるのかを2chやその他の掲示板等で
少しずつ解決していくといいよ。その積み重ねが君を成長させる。

Accessを使うならVBとかDelphiとか勉強して、セットでアプリ作ればいいかもしれませんね。
AccessはWEBアプリのDBとしては不向きだと思いますし。

教えて君ですいません
Accessでよく耳にする、ページ単位ロックってなんですか？
本とかで調べてみたけど、感覚的によくわかんないんです。
誰か、俺みたいな厨房にもわかるように、説明してくだしゃい。

会社の上司が「俺はAccessの本を4冊も読んでるからDBは
知ってるんだよ」と自慢気に語ってたんですが、
「SQLって何？ソフトの名前？」なんて聞いてきます。どうしてやりましょう？

0x100ｹﾞﾄ

>>254
その前にロックが解っているか、それが問題だ。(w

>>257
実はついさっき覚えたばっかりの言葉なんだ、ごめん。
ようは、自分がいじろうとするレコードを、他人がいじれなくすることだと
思ったんですが・・・
んで、そのレコードだけロックする奴が、行単位ロックとかいうやつで、表単位ロックってのが、恐らくテーブルごとのロックなのかなと・・
そこで、ページ単位・・・
大体、ページってなに？、1ページの大きさってどの位なの？
どうも、わからないんです。

・・・・もしかして俺、根本的に間違って覚えた？・・・・（ふあーん

九才あげ。すまんな。

>>258
ページっていうのは、まあ、コップだと思ってくれ。
DBがバケツで、データは水の分子（藁）。
ページサイズはDBによって違うし、自分で設定できるものもある。
#すげー分かりにくいな･･･漏れ。。。とてもDBﾍﾞｿﾀﾞｰにいるなんて言えねえ（ｗ

259 260 ありがとう
なんとなく、イメージがつかめてきた。
ようは、必要な範囲をまとめてガバッとロックすることなのですね。
んで、そのガバッと行くコップがページで、コップの大きさはDBや
設定で変わってくるということですよね。

ありがとうございました。
あとは、使用するシチュエーションを考えてみます。