TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
MariaDB
【安易ダサすぎ】データベース→DB→ドラゴンボール
OODB - オブジェクト指向データベース
個人情報保護法、どうする?
データベース系の仕事をしたくて探しているのですが
【オンメモリ%メモリデータベース【インメモリ】
OTN掲示板を生暖かく見つめるスレ
【オンメモリ%メモリデータベース【インメモリ】
【レア技術者】 ORACLE DEVELOPER R6i 【狂え!】
MSXでデータベースを作りたいのですが
【KVS】 Key-Value Storeを勉強するスレ
- 1 :2010/02/26 〜 最終レス :2016/03/29
- RDBMSの時代は終わるのか?
クラウド(笑)時代のデータベース技術KVSについて語ろう!
- 2 :
- お前の態度が気にくわない
- 3 :
- いままで無かったのが不思議なスレ
しかしたぶん伸びない
- 4 :
- もっと普及しないと
このスレで使ってる奴なんていないだろう
- 5 :
- ACIDが保証されないなんて
- 6 :
- NoSQLでこの前スレ立てたのに落ちたんだぜ…
- 7 :
- "distributed" が付かないと普通の dbm も入っちゃうんじゃ…
- 8 :
- perlとかのハッシュオブジェクトを保存するのもいけるな
- 9 :
- 具体的に、何を勉強すれば良いんだろうね
本とか出てる?
- 10 :
- 先月の software design で特集してたよ
- 11 :
- >>3
日本の SE でまともな DB 設計が出来る奴が居ないし必要ともされないから
性能が足りなければハードを買い増すことしか出来ないのが日本の技術者
>>5
今のキーワードはスケールしない ACID よりスケールしやすい BASE だろ
>>6
NoSQL という単語は個人的には意味が伝わりにくいと思う
>>9
XML, JSON
本ならオライリーから Hadoop 本がつい最近出てたな
- 12 :
- key-valueストアの基礎知識
http://www.shudo.net/article/Software-Design-201002-KVS/
- 13 :
- >>12
dクス、あとで読む。
- 14 :
- Hadoop本買ってきた。
KVSって読み出しの速度だけなのかと思ってたけど、
SUMとかMAXみたいな演算にもアドバンテージがあるんだな。
言われてみれば検索エンジンなんて、統計処理の嵐か。
よく、OLAP Cubeを構築するまででもないけれど、
単純なクエリで解決するには件数が多すぎるみたいなことがあって、
まぁ大体はインデックスの張り方とかクエリ最適化とかで逃げるんだけど、
こういう部分の代替になりえるかなぁ。
- 15 :
- sum()もmax()も読み出しそのものと言えるから当然だな。
しかも f(A,B) = f(f(A),f(B)) が成り立つから分散処理にも適しているし。
- 16 :
- 時系列で保存するデータなんかは更新処理がほぼ無いから、KVSとか向いてるんだろね。
これまでは何でもRDBMSに入れとけ、的な考えが多かったけど。
- 17 :
- それにしても人いないな。
試しに使ってみた人の感想とか聞きたい。
環境構築の手間とか、ものによって違うものだろうか。
- 18 :
- NoSQL 系は構築もそうだけど運用がね…
定番といえるモノがまだ無いし SQL でちょろっとクエリかければ済む仕組みじゃないから
最低限 perl や python で格納されたデータをごにょごにょする必要はある
- 19 :
- >>17
君がいろんなものを試して感想を書けばいいんじゃないかな。
- 20 :
- ちなみに>>17は「KVS」に何を期待してるの?
- 21 :
- 2ch クラスのデータアクセスが無いと KVS というか NoSQL 入れる意味が無いように思う
- 22 :
- そうなの?業務アプリのバックエンドとして
高速な読み出しが確保できるかなという淡い期待があったんだけど。
どういった面で意味がないのか教えてもらえると嬉しい。
- 23 :
- その高速性がいらないから意味がないんでしょ
○速い
×トランザクションなし
×障害保護弱い
×APIがプロダクトごとにばらばら
×テーブル結合なし
×詳しい人が少ない
×集計処理に弱い
高速性とスケーラビリティのために他をいろいろ犠牲にしているから
- 24 :
- >>22
CAP定理を学ぶんだ
- 25 :
- Key Value Storeについて ≪ さくらインターネット研究所
http://research.sakura.ad.jp/2010/03/17/kvs-intro/
ただのアニヲタ企業じゃなくて、研究もしてるんだな
- 26 :
- 保守
- 27 :
- >>25
つか、日本のIT企業で NoSQL を研究し実務に取り込んでいるのはこういうベンチャー系だけなんだな
大手は自力でサポートできるスキルが無いことをサポートシステムが無いと言う理由だけで
OSS には手を出さない
そもそも、国内には NoSQL を必要とするほどのトラフィックやトランザクションを捌くサイトや
Web システムが無い(Yahoo! Japan や 2ch くらい)
勘定系には BASE な NoSQL は向かないから論外
ということで、国内での利用は進まないと思う
- 28 :
- 結局業務アプリのSQLは集計処理がメインだからな。
遅い処理ってのは、あっちとこっちのテーブルをjoinしてunionして加重平均してなんてので、
その部分には分散KVSでも対応できないし。
- 29 :
- それ自体が独立しているシステムならいいけど、
他所と連携して動くシステム(営業部がSQLで課金情報引き出してるとか)だと、
SQLで扱えないのは導入の阻害要因になるな
位置付け的には、sqliteとかの、組み込みSQLの代用なんだろう。
あとは、大規模システムのコストを下げるために、SQL無しで割り切れるかどうか
なんでもかんでもOracleRACで組んでたらカネがかかりすぎる
- 30 :
- 普通のSIer向けの使いどころ何かないだろうか
- 31 :
- 何かと話題のツイッターのDBは、ApatchCasandoraっていうNoSqlを使ってるらしい。
- 32 :
- Twitter規模のサービスを作る必要があるなら使っても良いんじゃない?
- 33 :
- >>31
×ApatchCasandora
○Apache Cassandra
ttp://cassandra.apache.org/
- 34 :
- NoSQLという部類だとドキュメント型?データベースてのがあるみたいだけど
あれはどうなんですかね?
- 35 :
- 基本的にはJSONストア。
高速化はIndexだったりMaterialized viewだったり。
- 36 :
- 速いRDBMSが欲しかったらTimesTenでいいんじゃないか。
- 37 :
- 別に速さがだけが欲しいわけではないのでは。
スケールさせる必要が無かったらKVSなんて必要ないだろう。
- 38 :
- んん?求めているのは速さそのものだろ。
逆にそれ以外の部分をいろいろ割り切っているくらいだ。
- 39 :
- 機能としてシンプルだから
一般的なRDB知らない人はむしろ固定概念なく理解できるんじゃないですかね?
- 40 :
- KVSそのものの理解は容易でも、逆に要件をKVSの仕組に落とし込むのに
苦労すると思うな、そういう人は。
そんなレベルの人は、Postgresでも入れてキーと値だけのテーブルを
作って試してみる方が、情報も多いし後々役に立つと思うぞ。
- 41 :
- 日本国内でNoSQLが必要になっているシステムってそもそもあるの?
それによってはそんなものもあるよ、って知識だけで充分な気もする。
- 42 :
- ユーザー多くて負荷が高いサイトとか
mixi、グリー、楽天あたりはみんな使ってるんじゃない
- 43 :
- スケールアウトによる総合パワーが分散KVSのオーバーヘッドを上回る
規模じゃないと意味ないからなぁ。
はっきりいって、mixiとかそういう規模のシステムを作るんでもなけりゃ
>>41の言う通り知識で十分、本気で検討するもんじゃないと思うが。
- 44 :
- mixiを作らなくても、mixiアプリを作って当たるとあの規模のアクセスが来るぞ
俺はモバゲーアプリを作るので検討してる
- 45 :
- それ、シングルノードで済むような規模の話なんじゃないの?
想定しているレベルが全然違う。
シングルノードなら、使用する製品、チューニング次第で
KVSとRDBMSのどっちが上なんて一概に言えないぞ。まぁ
フリーのRDBMSはやや不利かも知れんが。
- 46 :
- なぜKVSなのか?なぜRDBMSではダメなのか?をしっかり理解しないと
なかなか使いどころが見えてこないね。
- 47 :
- カッコイイからだろ
Hadoopとか使いこなしてるとモテそう
- 48 :
- >>47
Hadoopがなにか理解してる?w
- 49 :
- MapReduce もややこしい名前だよな。
実際はソートしたりして、Map と Reduce ダケぢゃないし。
- 50 :
- このスレみてると、KVSってのもbuzzwordのひとつだなって思うよ。
- 51 :
- それでは、代わりにディストリビューテッド・シングル・カラム・ハッシュ・データベースと呼ぼうか
- 52 :
- 或は、ウルトラ・ファスト・クエリー・ウィズ・リミテッド・アグリゲーターとか
- 53 :
- ネーミングは大事だと思う。全部ひっくるめてNoSQLとかひどいw
- 54 :
- てめー俺が立てたNoSQLスレが一瞬で落ちたことをバカにしてんのか
- 55 :
- DB板でスレ落とすってよっぽどのことじゃね?
- 56 :
- うるさいうるさい!
- 57 :
- Cassandraが本命だと思ってればいいの?
- 58 :
- 今の時代はACIDを捨ててまでスピードを求めてるってことかな?
比較する必要があるのだからRDBMSを改めて勉強するにはいい機会かも。
- 59 :
- >>58
プリミティブだけど安くてスケールするデータストレージは提供
するからデータの整合性を保証する仕組みはアプリケーションに
あわせて各自手作りして下さい、みたいな流れだと認識している。
> 比較する必要があるのだからRDBMSを改めて勉強するにはいい機会かも。
比較の有無にかかわらずRDBの理論面や設計論は勉強しておいて
損はないと思う。
なんかNoSQL界隈ではスキーマレス->故に正規化なんて必要ない、
データモデリングも不要、お手軽です、みたいな風潮も一部で散見
されるけど、それは全くの誤解だと思う。
悪名高いRDBの正規化にしても、背景にある各種従属性に基づいた
データ構造の分析はデータの一貫性や更新時異常を理解する上で
RDBモデルに限らず他のどんなデータモデルにも適用可能なもの。
むしろRDBモデルはそういった理屈を実際のスキーマ設計に反映
する作法やノウハウが既に蓄積された大変お得なモデルだと思う。
他方でそれぞれの実装でバラバラなデータモデルや高速化手法を
採用しているNoSQLではそれぞれ手探りで妥当な落とし所を探る
必要があるわけで、まぁご苦労な話だなぁとは思う。
- 60 :
- ひとつのkeyに複数value持たせたいときは
もういっこテーブル?みたいなの作ればいいの?
- 61 :
- keyはともかくvalueはatomicでなくともよい実装が多い。
なので一つのキーに配列でも持たせればよい。
- 62 :
- そして再びコボラー型思想が栄えるのであった
- 63 :
- 結局使っていくと範囲取得とかしたくなる。
- 64 :
- テラメモリがエントリ鯖で使えるくらいにならんとね。
2年で倍として、10年後くらいか。
- 65 :
- 2Uのサーバで72GBとか積めるのは積める
- 66 :
- セッション情報のキャッシュを保存して複数鯖で共有するのにKVS使いたいんだけど
何が良い?
「ディスクに保存するmemcached」みたいな感じで使いたいんだが
- 67 :
- >>66
membaseなんてどう?
ttp://www.membase.org/
- 68 :
- なるほど、memcached互換を目指してるのか。現時点で安定して動くかな?検討してみる。
- 69 :
- TokyoTyrantあたりはmemcached互換だったよね。
結構互換のやつはあるっぽい。
- 70 :
- mixiみたいに落ちちゃうの怖い
- 71 :
- なんのための分散なんだか・・・
- 72 :
- memcachedのスレってない?
もうWebやるんなら必須ぽいけど
- 73 :
- たぶんこのスレ
- 74 :
- 必須ではないけどな別に
- 75 :
- 高信頼クラウド実現用ソフトウェア開発(分散制御処理技術等に係るデータセンター高信頼化に向けた実証事業)
http://www.meti.go.jp/policy/mono_info_service/joho/downloadfiles/2010software_research/clou_dist_software.pdf
小杉
- 76 :
- memcachedに画像を保存するには
base64エンコードするのが定番ですか?
- 77 :
- バイナリでそのまま入れないの?
- 78 :
- 入れられた。なんだできるのか。
- 79 :
- NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ/秒を実現
http://www.publickey1.jp/blog/10/nosqlmysqldenamemcached75.html
すげーじゃん
- 80 :
- mongoDBが良さそう
C#でもPHPでも使える
- 81 :
- mongodbはいろんな機能がついてて、
SQLの高機能に慣れてる人にも移行しやすそうだよね
- 82 :
- linqが使えるのが良い
他のコレクションとjoinできるのでRDBMSと同等のことはできるのでは
- 83 :
- これって東京なんたらとか京都なんたらとかでしょ
- 84 :
- Cassandra!
- 85 :
- 鬼の哭く街か・・・
- 86 :
- http://code.google.com/p/leveldb/
C++0x を使える環境にある人がどのくらいいるか分からないけど・・・
- 87 :
- >>61
valueには何でも入れられる。KVSそのものさえ。
- 88 :
- インデックスサーバを持たない場合、どっか適当なノードに
「このノードを追加しろー」ってメッセージを送出させるんだろうか。
- 89 :
- 構造によってちがうから一概に言えない
- 90 :
- >>88
Chord とかの話?
- 91 :
- skip graphとかをシミュレートしてみようと思う。
とりあえず、数値化するのはホップ数やメッセージ数だけでいいよね・・・。
- 92 :
- >>79
これも似たようなことかな?ttp://www.atmarkit.co.jp/fdb/rensai/dbwatch2011/dbwatch201111_02.html
(MySQL 5.6では)ラボで開発中のNoSQLオプションにも注目です。従来のRDBのようにinsertやselectだけではなくputやgetで、NoSQLデータベースのようにmemcachedでMySQL(InnoDBデータ)に話しかける機能も加わることになります。
- 93 :
- >Hadoop
KVSとhadoop系ってセットのものなの?
つまり2つの技術がセットになってやっと動くものなのか、
あくまで”1+1=2”なのか。。。
教えて下さいorz
- 94 :
- HadoopはHBaseとセットで考えたほうがいいんじゃね。
KVSはキーと値の組み合わせ。memmapdとか。
オンメモリのハッシュだと思えばOK
- 95 :
- mcachedだまちがいた
- 96 :
- レスd。
Hadoop/MapReduceとセットなのが、hBaseである。
hBase側から見ると、KVSは密な繋がりはなくて、あくまでone of them?
- 97 :
- KVSはデータ永続化用
Hadoopはデータ処理用
じゃないの?
- 98 :
- つまり、その2つはload処理とsave処理で繋がってるだけで、それ以外は無関係ってことですね。
何となく繋がりがあるイメージだったんだけど。。。
- 99 :
- HadoopはHDFS(ファイルシステム)とMapReduce(分散処理フレームワーク)で構成される.
Hbaseはそのデータストアとしてされる
- 100 :
- つまり、Hadoop/MapReduceのデータloadにHbaseは使えても、RDBとかは適切じゃないって意味ですよね?
結果のsaveなんかは、多分何のデータベースでもOKなんでしょうね。
- 101 :
- Hadoopが対象とするデータの想定はテラバイトやエクサバイトといったビッグデータだからデーRDBのI/O性能ではボトルネックになってしまうと思われます.
- 102 :
- データの一貫性少し犠牲にしても処理速度を→KVS
DBのでっかいダンプファイルから統計とったりしたい→Hadoop
大雑把に言うとこんな感じでしょ
- 103 :
- なるほど、なるほど。
「ビッグデータでもI/O性能OK」、かつ、「データを分散して持てる」(←あってますよね?)、
といったものでないと、Hadoopがマトモに動かないってことですよね?
次はなぜKVSではOKなのか(データが分散してるから、ビッグデータでもI/O性能OK?)なのかを考えてみまつ。
(教えて下さる方があるなら、このスレに書いて頂ければ、全部読んでます)
- 104 :
- あれ? >>102
>データの一貫性少し犠牲にしても処理速度を→KVS
>DBのでっかいダンプファイルから統計とったりしたい→Hadoop
KVS単体 VS Hadoop単体、ですか?
- 105 :
- Hadoopとkvsは対になるのではないはず。
- 106 :
- 再度、あれ?
http://d.hatena.ne.jp/okachimachiorz/20110619/1308490440
>基本的に単純に分散KVSを使いたいならHbaseにこだわる必要はない。
hBase=KVSだと思っていたのだが、違うのか。。。
色々読んでみると、KVSという一般的なデザインがあって、
Hadoop用データストアってのがhBaseで、それはKVSより機能が多い、
って感じ?
- 107 :
- KVSはカラムがKeyとValueしか定義されていない単純なデータ構造で代表的なものが
CassandraやHbase。
HadoopにデータストアとしてHbaseしか利用できないことではありません。
- 108 :
- なるほど。
Hbase (- KVS //HbaseはKVSの集合に含まれる
Hadoopのデータストアは、データ分散OK、ビッグデータでもI/O性能OK、が好ましい。
→RDBよりもKVS、その中でもhBaseが妥当じぇね?
ってことですね。
- 109 :
- LDAPスレはここにないよね?
あのクエリ言語はそれなりに面白いので、うまくバックエンドとして活用できれば嬉しいのだけど
- 110 :
- 実際に欲しいのはシンプルなBTreeデータベースなのに、うまくスケールする実装がないから
仕方なしにRDBMSを使っているってシーンが色々ありまして。。
- 111 :
- googleも最初はそうだったよね。
- 112 :
- Cassandraは、海外ではTwitterなど大規模なサイトでの導入事例
がたくさんあるようだけど、国内ではほとんど聞かない。
日本の大規模サイトで、Cassandra使ってるところってあるかな?
Cassandra、Write性能もスケールするっていうのは魅力的だな・・
RDBMSだとMasterがボトルネックになるのは不可避だろうし、かといって
Shardingをやるとアプリ側の作りこみがめんどうになる。
>>1
NoSQLのスレのが良かったんでは?
- 113 :
- >>41
Cassandraは牛刀すぎて、それ相応の規模を持ち合わせていないとなぁ。。
でもエンタープライズ市場やデータウェアハウス市場という実業分野では、素直にカネ払ってOracle導入するし
KVSは、多量のデータを扱う必要があるけどあまりカネ使えないっすー、というネトゲみたいな
虚業分野での導入実績が多いかんじ
- 114 :
- >>113
まったく的外れだな
いまどきエンタープライズ=Oracleなんて認識は時代遅れすぎる。
FacebookもDeNAも金持ってるがMySQLやNoSQLを使っている。
FacebookやAmazonは自社でNoSQLの開発もやっている
NoSQLとRDBの違いは予算ではない。
それぞれの長所、短所がある
NoSQLはビッグデータを扱える。
運用の負担が少なく、数百台のサーバーにスケールアウトできる
シンプルなデータモデルのためRDBでは実現できないようなパフォーマンスも叩き出せる。
- 115 :
- エンタープライズ=Facebook、DeNA、Amazon
って感覚にも問題ある
どこの企業もWebサービスが生命線ってわけじゃないし
- 116 :
- >>113
ビッグデーター関連の技術の活用や研究をしていてしかも金があるところ
だと日本だと例えばNTTがそうだね。
hadoop関連では国内でも有名だし、対外的にも国際学会に論文出している。
- 117 :
- 古典的なエキスパートvsプロフェッショナルの分類だと
エンタープライズと言えばプロフェッショナルで出来合いDB
Web企業はエキスパートだから自前かトガったツルシのDB。
といいつつもOracleだって今時の売りはビッグデータだ。
今やハードも持ってるしな。
- 118 :
- Oracleはカネ払えばベンダーが面倒見てくれるけど、KVSはそういう会社がまだないので。。
企業財産そのものであるデータベース分野で、「自分でソース読んで解決すればOK」みたいな
ソフトウエアは使わせてもらえない。
ネトゲみたいに「ゴメンゴメンぶっ飛んじゃったわ」で済む範囲ならいいかもしれないけど
- 119 :
- あのgmailでさえデータぶっ飛ばしてるし、まだエンタープライズ用途では様子見で。。
- 120 :
- KVSでも解析系は別に考えた方がよい。
- 121 :
- ところが、自前管理の方がデータぶっ飛ばしてる率が高そうだ
- 122 :
- gmailは扱ってるデータの規模がそもそも違う。
- 123 :
- データの規模って…ビッグデータはスケールしてなんぼでしょ?
そういうのでなかったら、Oracleで足りるし
結局ビッグデータでも維持のために専任管理者を置いておく必要があるけど、
もしもぶっとんだら、彼だけの能力でデータ復旧できるのかというとまだ微妙
そして彼の退職後に誰もメンテできないようだと、会社の存続が危うくなる
そういうスタッフを自前で置けないんだったら、Oracleを契約しておいた方が面倒がないような
- 124 :
- >>123
googleだってデフォでバックアップ取ってるし、
こっちがあーだこーだ言わなくても自動で修復もしてくれる。
oracleはちゃんとした会社だしサポートも営業体制も安定してるが、
ロストしてバックアップもダメになってる時だってあるし、ダメな時はダメ。
誰も無から有は作り出せない。
- 125 :
- もうfusion-ioさんでmysqlでnosqlに勝てちゃうだろ
nosqlはフラッシュ系ストレージのせいでオワコンになったんや
- 126 :
- そんなんその辺のクラウドじゃ使えませんやん…
- 127 :
- キャッシュ置き場ならいいかもしれないが、現状で一次データをKVSに置くのはさすがに怖い
- 128 :
- >>127
お前が怖いのは、根拠もなしにクラウドは危険だと言う同僚や上司を説得できないことだろ。
リスクの種類が違うからって危険とは限らないが、はなっから信用していない人間を説得するのは骨だ。
- 129 :
- >>128
「動かないコンピュータ」に載るような深刻な大事件がいくらか起こって、
その結果、「クラウドでこうやってはいけないバッドノウハウ集」がそれなりに溜まってきたら、
そろそろ入れようかと思うよ。
クラウド向きじゃない用途が明らかになって、「クラウドは欠点が多くて使えねーわ」って言う人が
増えてきたら、ちゃんと検討する。他人が地雷を一通り踏みまくってくれている。
クラウド関連記事が賞賛ばかりの状況では、マーケ盛んだな、ぐらいでまだ入れない。
機雷掃海は他人にやって頂くに限ります。
- 130 :
- >>123
Googleはデータやハードの故障への耐性ってのをまず考えてる。
安いマシンを並列に、で大きくなったんだから第一の関心がソレだ。
一部故障しても、少しの影響で済むような分散処理。
故障の素早い隔離と復旧そして同期のとりかた。
でも大事なのは、統計合計マシンだから本質的に少々データが
壊れてもあまり影響のないサービスだって事だ。
いわゆる業務システムじゃそうは行かんわな。
- 131 :
- ぶっ飛ばしても、障害報告を書いて謝って終わり、で済む安いデータならいいかもしれないけど
システムが止まると一日あたり数百万づつ売り上げが消える、という業務系ではまだ無理だよ
- 132 :
- MTTF・MTBF共に短いが可用性が高いというのがクラウドの特徴。
これが許せるか許せないかは業務系云々より、社会体質に依るんじゃないかなあ。
「あれ?動かないぞ・・・責任者出せ」みたいな体質の所だったらダメだろうし、
「あれ?動かないな・・・後でやり直そう、あ、動いた動いた、OK」みたいな体質のところだったらOK。
- 133 :
- そう考えると、やはりIT部門の責任者は相当な地位が必要だよなぁ。
システムは利用者の考え方をも変えてしまうのだから。
- 134 :
- 分散させれば障害に強くなる…って論は、現状の信頼性研究でも確実に断言できない所があるね
とあるエンジニアは、RAID5の存在を認めず事あるごとに批判し、RAID10以上を要求しているけど
それがマネーが動く業務システムってもんだよなぁ。。
- 135 :
- ネットワーク透過型のHashテーブルが欲しいな、と思ってKVSに当たるのだけど、
それの保守チームを確保できないから、やっぱりMySQLのように運用人口の多いRDBで代用してしまう
鶏と卵だなー
- 136 :
- 買ってくるんじゃ駄目なの?
- 137 :
- >>135
保守チームって何?
コードの隅々まで理解してる人達を養成でもしたいの?
- 138 :
- お勧めは?
- 139 :
- テスト
- 140 :
- スレチかもしれんのだけど、
エクスペディアの「このホテル、○分前に予約が入りました」
ってあれは、KVS使ってるのかな?
REDISかHBASEあたり?
探ってるんだけど、SAS入れたって情報しか見えてこない…
- 141 :
- RDBで十分でしょ
- 142 :
- 探って出てくるような話じゃないと思うんだが。
- 143 :
- 言われたら、「○分前に予約が入りました」は、RDBで行ける気がしました。
13万のホテルに最終予約時刻入れとけばいいから、対したこと無いですね。
- 144 :
- なるほどバカなんだな
- 145 :
- 千葉県松戸市六高台2-78-3
- 146 :
- ◎2ch勢いランキングサイトリスト◎
★+ニュース板
・ 2NN (推薦)
・ 2chTimes
★+ニュース板新着
・ 2NN新着
・ Headline BBY
・ unker Headline
★+ニュース板その他
・ Desktop2ch
・ 記者別一覧
★全板
・ 全板縦断勢いランキング (推薦)
・ スレッドランキング総合ランキング
・ ログ速
★全板実況込み
・ 2勢
・ READ2CH
・ i-ikioi
※ 要タイトル名検索
- 147 :
- ☆ 日本の核武装は絶対に必須ですわ。☆
http://www.soumu.go.jp/senkyo/kokumin_touhyou/index.html
☆ 日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、改憲の参議院議員が
3分の2以上を超えると日本国憲法の改正です。皆様方、必ず投票に自ら足を運んでください。
私たちの日本国憲法を絶対に改正しましょう。☆
- 148 :2016/03/29
- もともとRDBでなくてもいいものは、それぞれのシステムで実装していただけで、NoSQLのたぐいは昔からある。
でも結局、仕様の変化に耐えられなくてRDBになる。
SQL文は作られた時代から、古臭いけど、デファクトスタンダードだから仕方ない。
データベース破壊録カイジ
ADO DAO など接続方法について
いまの気持ちをSQLで表すスレ
オブジェクトデータベース LINQ, DLinq のスレ
個人情報保護法、どうする?
DB板自治・質問・雑談スレ
いまの気持ちをSQLで表すスレ
システム構築ベンダの実力
年金情報DBの構成を公開しろ
フィールド名は日本語にするか、英語にするか
--------------------
【不当要求】ボッタクって何が悪い?【違法】
検便統一教布教本部
【韓国】日本・安倍政権の『経済戦争』糾弾・・・青少年1000人宣言(写真)[08/11]
【フィギュア】ロシア女子を見守ろう56
黄色いヒトラー 安倍晋三
【3DS】世界樹の迷宮X(クロス) 185F
ソニーPCL社員の会
福岡の高校ラグビー Part.7
なぜ日本ではブラックサバスの知名度人気がないのか
△トレーラー海苔のひとパート2△
【従業員専用】佐川急便統一スレッド104【従業員専用】
ポップンミュージックpeaceはなぜ大失敗したのか4
モンスターハンター月下雷鳴 狩猟142匹
【ゆるキャン△】あfろ総合 Part18【mono】
コテ雑inラウンジクラシック part220
コンビニのトイレ Part1
アニメ銀魂ネタバレ有り雑談スレッド5
【財務省OB】森友問題は「財務局のチョンボと籠池被告のゆすり」「野党や朝日の追及は的外れ」
タバコ吸わない人間があと128日耐え抜くスレ
☆★本当の連想ゲーム25★☆
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼