告訴の趣旨
　被告訴人は、以下に該当すると考えるので、被告訴人の厳重な処罰を求めるため告訴します。
　職務経歴書を提示した事前面接を実施　または　偽装請負　または　偽装出向
　　労働者派遣法第26条（契約の内容等）、職業安定法第44条（労働者供給）に違反
　多重派遣・多重出向
　　労働基準法第6条（中間搾取の禁止）に違反
疎明資料
　事前面接日時、場所、出席者、資料のコピー、音声記録
　就業場所・就業期間・就業時間
　指揮命令
　　指示を誰が行っているかの記録、音声記録
　仕事で使う道具や、資材の負担（所有）のあり方
　　業務で使用しているパソコン・備品などの所有者
　契約書
　　請負、雇用契約書、出向指示など書面のコピー

刑事告訴ガイダンス　
★痴漢も民事でなく刑事事案ですが、裁判所が和解金を被害者に支払わせて解決するのが絶対的過半数です。和解で解決しない事案、つまり公訴までいって判例となる事例を探すほうが難しいことでしょう。
★録音は一方の当事者が取る限り合法です。※加害者に録音の同意を求める必要はありません。
★告訴状を検察に提出しても受理されなければ加害者側には知られることはありません。不受理の場合は何事も起きてないように粛々と振る舞ってください。
★告訴を取り下げるとき検察に提出した資料は全て返却されます。また検察があなたが提出した証拠をあなたの許可なく裁判の証拠として使用はできません。告訴を取り下げたのちの録音資料には当事者の立場が失われるため証拠能力はありません。
★和解時に告訴した事実は秘匿事項となります。犯罪者が秘密保持契約に違反した場合の損害賠償金は「即決和解」か「公正証書」で最低5000万円～にしましょう。支払いを拒否すれば強制執行手続きを（裁判不要）してください。
★派遣会社や事業会社が同業者に貴方の情報をリークしたなら同業者（又は競合他社）に弱みを握られることになります。
余程信用のおける相手でなければ、リークはできないでしょう。信頼のおける方にしても、その方の口が軽ければ、いずれ事実は分かります。
★リークの情報を得た事業者のなかには、リークの事実を貴方に教えてくれる方がいるかもしれません。その際は損害賠償金で得たお金の３割程度を謝礼金として渡してください。

http://wiki.postgresql.org/wiki/Slow_Counting/ja
やっとこの対応されたからなぁ。。これには参った

なんか勝負つきました？

ポスグレっていまだに.NETのデザインタイムサポートが実装されてないのかぁ
惜しいねぇ～

PHPと合うのは、MySQLですか？それともPostgreSQLですか？

>>706
関数とかの対応状況はどっちも同じじゃないかな？
「今は」ね

>707
「今は」ですか

MySQLにライセンス料が発生したら、PostgreSQLに流れますかねぇ
それともオブジェクト指向DBが取って変わるかも

>>708
今でも開発するソフトウェアがGPLで無い場合は、商用ライセンスが必要だと思ったが。
あと、オブジェクト指向DBが取って代わるなんて事は無いと思うよ。

今、わざわざ MySQL を選ぶ理由って何があるの？

705でつぶやいてる人もいたけど、
postgresqlに.NETのデザインタイムサポートがあればなぁ。
暇と知識と技術があれば、自作したいくらいｗ

あと、windowsOS上で、全文検索とか、MySQLのほうが楽そう。
ここで聞くことじゃないとは思うけど、
postgres9.2 & windows でいい日本語全文検索方法あったら教えて下さいな。

コンパイルが必要みたいだけど、ドキュメントに
「ほとんどのユーザには～バイナリ配布物をダウンロードすることを推奨します。」
http://www.postgresql.jp/document/9.2/html/install-windows.html
とまで書いちゃってるから、かなり敷居が高いのかなと…。

>>713
全文検索で日本語対応させるには、たったの1行書き換えるだけだし、
再コンパイル自体も難しいわけでもないし、問題ないと思うけどなぁ。

>>712 >>714
標準のN-gram検索は、3文字以上じゃないと使用されない
つまり、1文字や2文字の検索は適用されないので、「携」とか「携帯」で検索してもN-gram検索は適用されない
つまり、ただのシーケンシャルスキャンになって超遅い

textsearchに関しては、9.2に対応してないので実質使い物にならない
しかもゴミが残る仕様で放置されたまま

ポスグレでまともに使える全文検索がないので俺はMySQLを使ってる
まともな全文検索ができるようになったらポスグレに戻ってくるわ

まず、Postgreなんて略さない

MySQLに負けてるのは.NETサポートだけだ！

って認識でいいの？

>>719
そうだね
激安中古Adobe取扱店かなりやすいね(・∀・)キャンペーンだと
ホント庶民の味方だよググってみ

>ポスグレでまともに使える全文検索がないので俺はMySQLを使ってる

ぐるーーーんがの
ポスグレ用のやつもあかんのかな?

一応あるにはあるけど、
初めにお試し的なのがリリースされてからぜんぜん更新されてないな

用途が違うわ

質問
http://www.slideshare.net/matsunobu/ss-28303485
では、
6. PostgreSQL オープンソースの高機能リレーショナル・データベース 日本では
歴史的にコミュニティが強く、日本人コミッタも多数存在している 日本語ドキュ
メントも充実している

と書いてるけど本屋に行ってRDB関係の本探すと大体はOracle,SQLServer、で後は
MySQLとPHPとか
PostgreSQLの本は探せばある…みたいな感じだけどほんとに充実してんの？
勿論、amazonで検索すれば出てくるけどさ。

してる

>>726
本だけがドキュメントだと思っているのか?

>>726

つうか、この分析でMySQLが大規模向け、ポスグレが小規模向けっていう理由が
分からん。
LLがどうしたとかコネクションプーリングがどうしたで変わるのか？

なんか無理矢理MySQLを大規模向けにするための方便にしか聞こえない。

>>728
これからDBを勉強したいって思ってる人間が本屋に行って沢山並んでいる奴と殆ど並んでいない奴とを比較して
どれを勉強しようかってなると…とか思わないですか？

ま、仕事で有無を言わさずやらされてたり、最初からそれ専門でやってる連中は別なんでしょうがね

思わんなあ
本屋が全ての人がネットで仕事するのか

>>730
そこまでの素人だったら、こういう本から始めてほしいね。
『SQL ゼロからはじめるデータベース操作』
http://www.amazon.co.jp/dp/4798118818

>>726
最新版の公式ドキュメントが日本語で翻訳されるから本が必要な部分が少ないのだよ

>>729
だってMySQLの人だもん

MySQLはそろそろ避けたい
でもPostgreSQLは古いバージョン触った事ある人なら怖くて選択できない

そして昔からずっとpostgres使ってきている人は今のpostgresの優秀さをよく知っている。

>>737
逆じゃない？
俺は昔にMySQL使ってみてトラウマになって、いまだにMySQLだけは試してみようとも思わない。
本格的なSQLの仕様とか日本語(マルチバイト)対応の面とか、MySQLに対する優位性はゆるぎがなかったけどなぁ
今は知らないが

>>739
データベースをまったく知らんヤツにとっては、
10年ぐらい前MyISAMが主流だった頃
PostgreSQL＝重い、わけわからん　MySQL＝軽い、使える
だったよな。

トランザクションも使えないMyISAMがRDBMSとして
「使える」って判断しちゃうヤツが多かったのは
Web2.0とか言い出す寸前ぐらいでにわかwebプログラマが
MySQL+Perlが正義みたいな風潮だったから仕方が無いのかもね。
まあ掲示板に毛が生えた程度の用途ならMyISAMで充分だったけど。

pgsqlが安定して速いmysqlは検索が速い
じゃなかたけ？

>>741
それ以前にMySQLは単なるサブセット
子供のおもちゃみたいなもん




だった


今はしらん

>>741
MySQL INNODBとPostgreSQLはほぼ標準的なDBでそこそこリソース必要。
MySQL MyISAMはDBとしては不完全な代わりにリソース少なくても軽くて速かった。

MySQL最強説が出た頃は、引退させたWindows3.1～95用PCに
UNIX類(Redhat Linuxとか)インストールして自宅鯖にしてたような時代だから、
INNODBもPostgreSQLも「重い。使えない。」になったのは仕方ない。

>>743
MySQL最強説なんてあったかな？
あったとしても、まだサブクエリーも使えないRDBMSと呼べないような代物だったころの話でしょ？

>>744
スマソ。レス番記載しなかったから話が繋がってなかった罠。

10年ぐらい前の「データベースをまったく知らんにわかWebプログラマ」の間に
LAMP(Linux+Apache+MySQL+PHP/Perl/Python)とか流行って、
「MySQL最強！PostgreSQLなんて劣化Oracleイラネ」な風潮があったって話だ。

もちろん実態としてはMySQLはMyISAM主流でRDBMSなんて呼べない状態だったし、
個人的には「あんなもんじゃデータベースの本領発揮出来ない。」って思ってた罠。

LAMPの時代だと
「トランザクションの無いRDBMS」
って使い物になんの？
と疑問だったな。
後日、アプリ屋と会話する事があって、アプリ側で競合回避のロック機能を
入れたりとかしてるとか聞いて大変そうだなと思ったっけ。

LAMPが流行った頃、自分がかかわる案件はLAPPに誘導してた。
（そしてその企みはおおむね成功してた。）

ファイルシステムしか経験がない連中にとっては、
MySQLは検索機能を実装済みのファイルシステム程度だったんだろうと思う。

MySQLもPostgreSQLも関係ないからスレ違いっぽいが、PGの実態として・・・
N88BASIC時代からやってる人が書いたAccess+VBAのシステムをメンテして、
「あー、この人はSQLを理解する気なんて一切無いのね。」って思ったりした事がある。
テーブルもレコードファイルの考え方で設計されてたし。
まあもっとも、AccessのSQLはクソ使いにくくてVBAでゴリゴリ書きたくなるのも確かだけど。

MySQLの方がPostgresSQLより速い？とかの説がいまだにあるんだけど、理解できない。
7のころからPostgresSQLを使っているが（Oracleから移行した）、処理が遅くて問題になったことは一度もないんだんが？
現行のPostgresSQLで処理能力に問題があるレベルだったら、Oracleとかでも同じじゃないかな？
ハード面を見直す必要があるよね。
うちのはハード構成としてはかなり強力。もちろんAPサーバとは別運用している。

むしろ Oracle 遅ぇ！

>>748
よくある噂話はmysqlの方はチューニングして、pgsqlはそのまんまで
検索テストをしたとかなんとか。
pgsqlもちょとチューニングしたら、爆速になったとかなんとか。