平凡な事を非凡な言葉で語るよりも
非凡な事を平凡な言葉で語りたい
小難しい単語を並べるパズルには興味ないしなぁ。
完璧ではない、と言える自信
「後で修正できる」んなら無問題だと思ってるです(程度問題ではありますが)。
っつかむしろ「全く傷のない玉」なんて想像つきませんし。
そんなものを作るくらいなら「傷を見つけたら磨いてきれいにしてみる」ほうが、よっぽど足回りが早そうで。
色々な見地があるものだなぁ、と
元ネタはこちら。
上流の技術者はSQLを高いレベルで習得すべき
http://el.jibun.atmarkit.co.jp/g1sys/2009/06/sql-9a31.html
そこで、以前からの蒸し返しですが、「上流の技術者はSQLを高いレベルで習得すべき」と改めて一度、声を大にして言いたい。
………はぁ。
えと…おいちゃんの個人的見解としては。
・DBのスケールアウトが限りなく厄介な上に、複雑なSQLは、どう頑張ってもある程度以上性能が出ない
・業務ロジックが散らかると非常に困る
・そもSQLが「製品による方言」多すぎる
・DBMSは「１レイヤー」の本来抽象化されるべきものだと思ってるので。入れ替えが面倒な状況は可能な限り忌避したい
などの理由から。
本質的にRDB(リレーショナルデータベース)を好んでません(言い切ったし)。
まぁ…厳密には。
「高いレベルのSQL」が何を指しているのか…がそも不明(未定義)なのですが。
で、興味深いのが。
「そもSQLってリレーショナルデータベースという概念からするとかなり奇異な設計と実装だよね」という話が出てきたりは、しないんですよね。
ついでに言うと「ちゃんとリレーショナルデータベースという数学の集合論についてどこまで学んだか?」と聞いて、クリアな回答が帰ってきた試しもないですし。
もちろん。
以前ここ( http://d.hatena.ne.jp/gallu/20090510/p1 )でも書きましたが。
複雑なSQLを、手続き型な頭ではなく、ちゃんと「集合論を前提にした」書き方で書く「事ができるスキルを持つ」という事は、とても重要だと思います(そういう意味で。二度書きになりますが、ミックさんの書籍＆Pageは、大変に素晴らしいと思ってます)。
それを実際に業務で「使って良いか？」と問われると…おいちゃんの経験は、明示的に「No」と言ってくるわけなんですね。
ついでに言いますと。
無論技術がある程度以上しっかりしている事が大切なのは言わずもがななのですが(ただ…だとするなら。プログラミングからネットワークからサーバまで一式言及せにゃならんと思うのですが)。
いわゆる上流工程(って言い方おいちゃん嫌いだけど)であれば。それに加えて、プロジェクトマネージメント 企画 立案 提案 現状分析 問題定義 プレゼンテーションその他諸々。言及せにゃならん所はもっとたくさんあると思うのですが。
まぁ…とりあえず「色々な視点があるものなのだなぁ」とか思ったので、軽めにmemo。
