SQLだけ苦手
業務でSQLを扱っているけどいまいち理解できないです。
INNER JOIN?何が「内側」なのか理解できない
LEFT OUTER JOIN?はぁ?何を基準に「左」なんだ?しかも「外側」・・・
抽出条件がWHEREだと?条件はIFかWHENだろうが!
直積とデカルト積の違いは?要するに「総当たり」なの?
こんな調子で業務に支障が出始めてます。
どうしたら理解できる? むしろ、SQLしか理解出来ないSIerは多いし、あんまり理解出来てもいない。 1個のSQL文が数百行とかあってそれをメンテしてる
正直気持ち悪い
SQLを関数やメソッドのように考えてはいけないんだろうね。 あったなぁ
クリスタルレポート使ってるとそんな感じになる INNER JOINは使わないほうがいい。
エビデンス作業をホカの人に回せなくなるぞ。 >>1
一度DBエンジンを実装してみたらよくわかるようになる >>1
頭悪いくせに理屈っぽそうだなw
ミック本読め ほんとうに難しいのはSQLそのものよりビジネスロジックだと思う とても簡単な自宅で稼げる方法
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
VQI8B 良く出来るプログラマーほど苦手らしい
しかし大量のデータを扱ったり、インポートエクスポートやったりすると、なんかDBの良さが見えて来る。自分で検索アルゴリズム作ったりするよりも速いし、そういうの見せられると自然と改宗する。 >>18
業務SEはDB好きなんだけど、オープンソースで発言力大きそうな人はDBエンジンがブラックボックスなのと、使い道が理解出来ない世界で生きてる感じがするわ。
KVSでなんとかなると言い切る プログラマでもなぜかSQLになると平気で明らかに重たい処理をデータベースに要求してくる。
どう処理されるのかまったく考えていないのだと思う。 暗号化された文字列でテーブルフルスキャンを何回か行う設計
速度はしらない 手続き型とは考え方が違う
理解出来るまでやるとしか言えん >>1はSQLの払い出し作業だけをやってんのか?プログラマのようには見えんし
数百行のSQLとかなんか俺の昔の職場と被るんだがまさか某携帯会社関連じゃないよな? >>20
チューニング出来る奴ならフルスキャンは不味いと考えるが、件数はどうでもよく動いて納品出来たらあとシラネが普通だよ >>23
高速化のためにJRの改札もそんなんだっけ 今からでもSQLの文法変えてほしい
SELECTが射影でWhereが選択
SELECT前にあってWhereがSELECT前のグループにかかる
きがくるっとんのか 自分でコンバータ作ればいいだけ。
セキュリティの観点からソースいじってsqlの文法変えるのはアリとは思うけど、使いづらいってのは経験不足なだけ コンバーターのぶん処理が余計になるし
メンテでそこ疑わなきゃいけいないし
引継ぎ者が誰も知らない文法覚えないといけないし
選択枝としてありえない
標準化委員会が新しいまともな文法のSQL作って敷衍するべき >>29
動的SQLという言葉は分かります?
大きなプロジェクトだとそういうの許されないんだけど。
LAMPの人には世界が違い過ぎるか