[掲示板に戻る]
レス送信モード
E-mail
コメント
削除キー(記事の削除用。英数字で8文字以内)
  • 添付可能:GIF,JPG,PNG,WEBM,MP4. 3000KBまで. 現在2294人くらいが見てます.
  • スレッドを立てた人がレスを削除してスレッド内のみアク禁にできます.
  • メール欄に「id表示」と入れてスレッドを立てるとid表示にできます.
  • 削除依頼が閾値を超えるとidを表示します.
  • 政治はだめ. 同人関連のアップロード依頼はだめ.
  • 1スレッド最大1000レス,最低1時間保持.
  • 管理人への連絡は準備板 ご意見へ. 削除依頼は記事番号を押しdelを押して下さい.
  • スマホ・携帯ふたば入口 この板の保存数は30000件です. 規約
  • 新しい板: 人工知能 ZOIDS
fu6787990.png[見る]


画像ファイル名:1780495406613.jpg-(16007 B)
16007 B26/06/03(水)23:03:26No.1436421954+ 00:53頃消えます
最強のデータベースって何なのん
このスレは古いので、もうすぐ消えます。
126/06/03(水)23:03:58No.1436422122そうだねx14
そんなものないよ
226/06/03(水)23:05:13No.1436422520そうだねx5
岩に彫る
326/06/03(水)23:05:38No.1436422662+
ポスグレでないことは確か
426/06/03(水)23:06:48No.1436423050+
CSV
526/06/03(水)23:06:50No.1436423061そうだねx2
用途によるとしか言えん
626/06/03(水)23:07:24No.1436423254そうだねx4
>MySQLでないことは確か
726/06/03(水)23:08:14No.1436423538+
富士通の最強DB
826/06/03(水)23:08:34No.1436423633+
憎きあんにゃろめ
926/06/03(水)23:08:54No.1436423753そうだねx5
インストールベースではsqliteかもしれない
1026/06/03(水)23:08:59No.1436423783+
全てのデータをメモリに載せる設計にしたらさいつよになるのでは
1126/06/03(水)23:10:03No.1436424134+
まず最強の定義がわからん
1226/06/03(水)23:10:11No.1436424165+
>富士通の最強DB
たまに触る機会あるけど毎回なんだコレになるわ
1326/06/03(水)23:10:26No.1436424250+
インメモリデータベースというのはある
1426/06/03(水)23:10:35No.1436424313+
oracleを買えばいいと思うよ
1526/06/03(水)23:11:39No.1436424649+
>まず最強の定義がわからん
信じられないクソみたいなクエリ流してもちゃんと帰ってくるというなら結局Oracleになるからな…
1626/06/03(水)23:12:35No.1436424961+
勝手に解釈されて間違ったデータ帰ってくるくらいならエラー出してもらったほうが良いわ
1726/06/03(水)23:12:43No.1436425009+
>DB2出ないことは確か
1826/06/03(水)23:13:41No.1436425302+
>oracleを買えばいいと思うよ
クソ高いしバグも山程あるけどまあコイツが一番信頼はできる
1926/06/03(水)23:13:42No.1436425305+
もしかしてOracleでやってること他所でやったらだめだったりする…?
2026/06/03(水)23:13:43No.1436425308+
>インメモリデータベースというのはある
当然だけどSaaSでも結構高いんだよな
2126/06/03(水)23:14:22No.1436425518そうだねx2
クソテーブルぶつけ合って壊れたら負け
2226/06/03(水)23:14:59No.1436425695そうだねx3
使い方次第でどれもが最強にも最弱にもなれる
2326/06/03(水)23:15:00No.1436425702+
SymfowareなんだっけUNION句に何か制約があったような…
あと日付リテラルで指定するときにDATEとかTIMESTAMPとか
明示しないといけなかったんだったか…
2426/06/03(水)23:15:55No.1436425984+
>oracleを買えばいいと思うよ
金はあるけど技術が怪しいなら一択ではある
2526/06/03(水)23:18:18No.1436426777+
時代はNoSQLだよ!
2626/06/03(水)23:18:23No.1436426812+
思想が強いデータベース
VACUUMは甘え
2726/06/03(水)23:19:38No.1436427199+
>インメモリデータベースというのはある
昔アローヘッドの話はめっちゃ聞いたな
2826/06/03(水)23:20:51No.1436427582+
いっぱいつかわれてるからSQLiteが最強
2926/06/03(水)23:21:19No.1436427728+
>もしかしてOracleでやってること他所でやったらだめだったりする…?
テーブル結合すら基本やるなってDBはそこそこあるからな
特に国産のは
3026/06/03(水)23:21:31No.1436427794+
まあ一つ間違いないのはDb2と関わる羽目になりそうになったら逃げろ
3126/06/03(水)23:22:20No.1436428041+
漢ならdBASE
3226/06/03(水)23:22:53No.1436428189そうだねx1
たくさんあるの邪魔
一つでよくない?
3326/06/03(水)23:22:57No.1436428215+
人間の脳を繋げるしか
3426/06/03(水)23:23:43No.1436428466+
SQLiteの型が嫌いなんじゃ
3526/06/03(水)23:24:37No.1436428758+
>SymfowareなんだっけUNION句に何か制約があったような…
>あと日付リテラルで指定するときにDATEとかTIMESTAMPとか
>明示しないといけなかったんだったか…
そもそも構文が独自過ぎて他の経験が活かせないんよ
3626/06/03(水)23:25:10No.1436428936+
>たくさんあるの邪魔
>一つでよくない?
テーブルも同じである!!
3726/06/03(水)23:26:47No.1436429409+
SQL Serverはプロファイラがデフォルトで使えるのがすごい楽
3826/06/03(水)23:26:49No.1436429421そうだねx1
Excel
3926/06/03(水)23:27:09No.1436429520+
複数扱ってると日付関数とかで画像みたいな感じになる
fu6787990.png[見る]
4026/06/03(水)23:27:33No.1436429621そうだねx3
最強ではないけどWindowsオンリー環境ならまあまあ使いやすいよねSQLSever
4126/06/03(水)23:27:56No.1436429755そうだねx2
>まあ一つ間違いないのはDb2と関わる羽目になりそうになったら逃げろ
DB2そのものも厄介だけどDB2が動いてる案件なんてほぼ間違いなくろくでもないやつだからな…
4226/06/03(水)23:28:00No.1436429772+
HiRDB!
HiRDB!
4326/06/03(水)23:28:06No.1436429795+
自分で書いたクエリを信用しきれるユーザーもそんなにいないだろうし金あったらoracleでいいだろ…
まあ金ないんだけど…
4426/06/03(水)23:28:19No.1436429858+
Oracleの管理メンテ機能使いこなせてないけどPosgreSQLに流れると今度は何でも自分でやらせて死ぬんだろうな
4526/06/03(水)23:28:33No.1436429919+
>HiRDB!
>HiRDB!
一回だけ使ったけど二度と触りたくない
4626/06/03(水)23:28:54No.1436430014+
NoSQL!
4726/06/03(水)23:29:35No.1436430211+
SQLServerから離れられない
4826/06/03(水)23:29:49No.1436430272+
oracleはクソみたいなスキーマ設計してクソみたいなクエリ書いてもそこそこ動くからな
問題は賢いオプティマイザに頼りすぎてoracleでも無理な資産にたどり着きがちなとこだけど
4926/06/03(水)23:30:55No.1436430572+
どこがと言うかそもそも方言強いな…ってなるSQL
oracleがシェア獲ってるからそれに従う風潮っぽいけど
5026/06/03(水)23:30:58No.1436430593+
誰かtidbやyugabytedbを実務で使っている「」はいないのか
5126/06/03(水)23:30:58No.1436430595+
Accessを授けよう
5226/06/03(水)23:31:17No.1436430674+
>SQLServerから離れられない
サイベース自体良いDBだったからMS製品にしては素性が良い
5326/06/03(水)23:31:45No.1436430825+
なんでDBで書き方統一できないの
5426/06/03(水)23:31:47No.1436430832そうだねx1
>>まあ一つ間違いないのはDb2と関わる羽目になりそうになったら逃げろ
>DB2そのものも厄介だけどDB2が動いてる案件なんてほぼ間違いなくろくでもないやつだからな…
忍び寄るメインフレームの影
5526/06/03(水)23:33:10No.1436431164+
>誰かtidbやyugabytedbを実務で使っている「」はいないのか
yugabyteを実務で使ってる知り合いは見たことある
ゴキブリとかもポテンシャルは凄そうなんだが
5626/06/03(水)23:33:19No.1436431206+
SELECT文でカラム複数出せることを知らないやつが書いた形跡があるものを見てしまったんだ
怖いか?
5726/06/03(水)23:33:50No.1436431344+
OracleはライセンスのがめつさとPL/SQL以外はいいと思う
5826/06/03(水)23:33:57No.1436431361+
標準SQLに従ってくだち!
5926/06/03(水)23:34:11No.1436431437+
>SQLServerから離れられない
MSにしてはいいと思う
ロードとアンロードはもっと使いやすくすればいいのにと思うけど…
6026/06/03(水)23:34:21No.1436431479+
カタお茶
6126/06/03(水)23:34:34No.1436431529そうだねx2
まあ実務だと移行とか解読性も考えて選ばないと後々すごいことになるからね…
6226/06/03(水)23:34:52No.1436431586+
SELECT *
6326/06/03(水)23:34:57No.1436431619そうだねx4
維持管理が楽なら何でもいい
っつうか維持管理こそもっとも難易度が高い
6426/06/03(水)23:35:16No.1436431698+
例外は運用で弾くからへーきへーき
6526/06/03(水)23:35:50No.1436431830+
秘儀ロックエスカレーション
6626/06/03(水)23:36:30No.1436431983+
>維持管理が楽なら何でもいい
>っつうか維持管理こそもっとも難易度が高い
最近は製品寿命短くてつれえわ
そろそろ引退したい
6726/06/03(水)23:39:31No.1436432774+
じゃあ最強のDBはOracleということで次は最強のDWHを決めようか
6826/06/03(水)23:41:30No.1436433305+
これからはレイクハウスが流行るって聞いた
6926/06/03(水)23:43:29No.1436433847+
技術選定できる人って凄えなと思う
7026/06/03(水)23:43:34No.1436433874+
もうポスグレって流行ってないの?
俺これしか使えないんだけど
7126/06/03(水)23:44:09No.1436434021+
SQLite
7226/06/03(水)23:44:11No.1436434032+
DBのbranch機能には可能性を感じてるがまだ実務で活用できてない
7326/06/03(水)23:44:38No.1436434154+
オープンソースのデータベース作る人って何考えてるの
7426/06/03(水)23:44:52No.1436434211+
DDL渡すだけでAIが複雑なSQLさっと組んでくれるからありがたい…
7526/06/03(水)23:45:01No.1436434245+
なんで一つの会社でオラクルだったりSQL Serverだったりするんですか?
7626/06/03(水)23:45:02No.1436434251そうだねx2
>もうポスグレって流行ってないの?
>俺これしか使えないんだけど
だいぶ元気だと思うよ
7726/06/03(水)23:46:06No.1436434492+
AWSのなにか
7826/06/03(水)23:46:57No.1436434711+
ポスグレくんは立場確立させてるから
7926/06/03(水)23:47:02No.1436434729+
>なんで一つの会社でオラクルだったりSQL Serverだったりするんですか?
その時々の情シスの上の気分のせいですかね…
8026/06/03(水)23:48:02No.1436434968+
Oracle維持する金無くなったら大体ポスグレに移行するから安泰じゃ
8126/06/03(水)23:48:46No.1436435153+
>なんで一つの会社でオラクルだったりSQL Serverだったりするんですか?
選択する人は使い勝手や性能を理解しておらず、よくて昔触っていた程度で今のことはわからず
そこから生まれるコストなんて考えずにライセンス代で選択する
8226/06/03(水)23:49:30No.1436435340+
>たくさんあるの邪魔
>一つでよくない?
SQLの構文に関してはそう何が方言だ
8326/06/03(水)23:49:43No.1436435396+
>オープンソースのデータベース作る人って何考えてるの
技術的な好奇心半分ビッグテックへの反感半文ぐらいだと思ってる
8426/06/03(水)23:49:50No.1436435431+
実際AWSで常軌を逸したスケールアップとスケールアウトすれば大体解決するよね
8526/06/03(水)23:50:12No.1436435525+
AIのトークンが安いうちにOSSのDB組み合わせた最強DB作りたい
8626/06/03(水)23:50:31No.1436435615そうだねx1
>実際AWSで常軌を逸したスケールアップとスケールアウトすれば大体解決するよね
そして請求書を見た上司にぶん殴られるまでがワンセット
8726/06/03(水)23:50:54No.1436435708+
dynamodbだよな
8826/06/03(水)23:52:13No.1436436091+
うわああああああ!!!!!mdbだあああああああ!!!!!
8926/06/03(水)23:52:18No.1436436107+
A5SQL Mk-2さ!A5SQL Mk-2さえあれば何も怖くない
9026/06/03(水)23:52:31No.1436436167+
マジレスするとアダプタを用意してどんなデータベースでも接続できるようにする
9126/06/03(水)23:52:49No.1436436252+
SQL文わかりづらくない?何とかならないの?
9226/06/03(水)23:53:08No.1436436323+
>SQL文わかりづらくない?何とかならないの?
AIに丸投げ
9326/06/03(水)23:53:13No.1436436358+
mongoDBそんなに性能いい?
別にmariaDBでDBエンジン変えれば良くない?
9426/06/03(水)23:53:45No.1436436520+
>SQL文わかりづらくない?何とかならないの?
正規表現より読みやすいし書きやすいと思うよ
9526/06/03(水)23:54:16No.1436436659+
>>SQL文わかりづらくない?何とかならないの?
>正規表現より読みやすいし書きやすいと思うよ
そんな相撲取りよりデブじゃないデブみたいなこと言われても
9626/06/03(水)23:54:57No.1436436834+
INSERT と UPDATE でフォーマットがまるで違うのはマジでクソ
普通その二つはワンセットだろうがよ」…
9726/06/03(水)23:55:07No.1436436880そうだねx1
複数テーブルにまたがる値取ってくるとき
クエリ芸やるより素直に2回読みに行ったほうが良くない?ってずっと思ってる
9826/06/03(水)23:55:09No.1436436888そうだねx3
真面目な話SQLは可読性という意味ではかなりマシな方だと思うデブ
9926/06/03(水)23:55:11No.1436436893+
>DBeaverさ!DBeaverさえあれば何も怖くない
10026/06/03(水)23:55:42No.1436437025+
>>DBeaverさ!DBeaverさえあれば何も怖くない
なんであんな便利なものが無料で…?Accessすら読み込めるじゃん
10126/06/03(水)23:56:19No.1436437182+
>INSERT と UPDATE でフォーマットがまるで違うのはマジでクソ
>普通その二つはワンセットだろうがよ」…
仮想テーブルでSELECT介してやると揃って気持ちいい
10226/06/03(水)23:56:21No.1436437186+
>真面目な話SQLは可読性という意味ではかなりマシな方だと思うデブ
見れば仕様が掴めるのはデカい
10326/06/03(水)23:56:30No.1436437220+
>複数テーブルにまたがる値取ってくるとき
>クエリ芸やるより素直に2回読みに行ったほうが良くない?ってずっと思ってる
実行計画でうまくやるとかあんのかもだけどWebアクセスログとかだとさすがにきつい感ある
10426/06/03(水)23:56:42No.1436437276+
>複数テーブルにまたがる値取ってくるとき
>クエリ芸やるより素直に2回読みに行ったほうが良くない?ってずっと思ってる
1回目と2回目でデータが変わって無いことが担保されるならそれでもいいよ
10526/06/03(水)23:56:58No.1436437329+
ここ3年くらいsnowflakeしか使ってない
10626/06/03(水)23:57:38No.1436437490+
>1回目と2回目でデータが変わって無いことが担保されるならそれでもいいよ
Transaction切って2回読むぜ
10726/06/03(水)23:58:04No.1436437591+
混乱するほど複雑なSQL書かなきゃならないのは設計段階で駄目なのでは?
10826/06/03(水)23:58:50No.1436437784+
オ、Aurora DSQL…
10926/06/03(水)23:58:51No.1436437790+
SQLServerのソートってどういうルールなんだ?
記号系は文字コードに従ってないような…
11026/06/03(水)23:58:52No.1436437798+
ストアドプロシージャいいよね…
11126/06/03(水)23:59:03No.1436437846+
ネストが深くなければSQLは読みやすい言語だと思うんだよな
11226/06/03(水)23:59:18No.1436437895そうだねx5
分析でクエリ書く身としてはどんなに設計がクソでも今あるテーブルからクエリを書かなきゃならんのだ
11326/06/03(水)23:59:44No.1436437983そうだねx3
>混乱するほど複雑なSQL書かなきゃならないのは設計段階で駄目なのでは?
今更そんなこと言われても困るわ!
11426/06/04(木)00:00:22No.1436438143+
> オ、Aurora DSQL…
知らなかったそんなの…
11526/06/04(木)00:00:30No.1436438175+
いまならGoogle spannerいいよ
マジでいいよ
11626/06/04(木)00:00:34No.1436438193+
timestampとかdatetimeとかで曜日とか週番号とかにindex貼れるDBって何処かに無いのかな
11726/06/04(木)00:00:34No.1436438194そうだねx1
>分析でクエリ書く身としてはどんなに設計がクソでも今あるテーブルからクエリを書かなきゃならんのだ
フロントアプリは10年で入れ替わってもDB設計は30年以上維持されたりするからな
11826/06/04(木)00:00:37No.1436438204+
>ストアドプロシージャいいよね…
数千行のストアドプロシージャいい…
誰が使ってんだよこんなの
11926/06/04(木)00:00:37No.1436438205+
PostgreSQLみたいに複数利用想定のデータベースってないの
PostgreSQLは全然柔軟じゃない
12026/06/04(木)00:00:44No.1436438236そうだねx1
>混乱するほど複雑なSQL書かなきゃならないのは設計段階で駄目なのでは?
これは10年以上前に別の会社さんが作ったヤツなので…
12126/06/04(木)00:00:46No.1436438245+
どうせ後付けでどんどんぐちゃぐちゃになる
12226/06/04(木)00:00:51No.1436438256+
昔夢描いたAIが実現した今
データベースの最初の設計だけは必死に頭抱えて考えなきゃならない
12326/06/04(木)00:02:58No.1436438738そうだねx4
論理削除の delete_flag を DB設計に入れるなって話が定期的にバズるけど
現場の運用を考えると大変便利な小刀なのである
12426/06/04(木)00:03:27No.1436438839そうだねx1
クエリは作り直す機会はあんまりないけど拡張する機会はなんかあるから冗長になってゆくもの…
12526/06/04(木)00:04:26No.1436439049+
論理削除の読み取りにはVIEWを用意するとかよくあるよな?
12626/06/04(木)00:04:34No.1436439076+
そもそも今のグッチャグチャのデータを整理するためだけにDBのテーブル設計やり直しとか絶対やりたくないし予算がつくわけないもん
12726/06/04(木)00:05:27No.1436439290+
最強のDBは勝手に死なないDBである
あと勝手に重くならないやつ
12826/06/04(木)00:06:43No.1436439586+
>論理削除の delete_flag を DB設計に入れるなって話が定期的にバズるけど
そんなのあったんだ
なんなら全テーブルに欲しいけど
12926/06/04(木)00:07:39No.1436439842そうだねx1
運用たいしたことないウェブ系ばかりやってるせいで医薬とかオンラインゲームとかやってる人たちには畏敬の念があったりする
13026/06/04(木)00:08:12No.1436439978+
一番使われてるDBはExcelだから最強のデータベースはExcelに決まってるだろ
13126/06/04(木)00:10:00No.1436440430そうだねx1
論理削除の代わりにステータスの変遷を記録するテーブルを作れってのは見たことある
正しいのかどうかは知らん
13226/06/04(木)00:10:03No.1436440442+
>ネストが深くなければSQLは読みやすい言語だと思うんだよな
WITH使えるようになってからスッキリした
でもさらに複雑にできるようになった
13326/06/04(木)00:10:38No.1436440595+
100レコードくらいで事足りるシステムに携わりたい
13426/06/04(木)00:12:39No.1436441106+
Oracleとかお高い最強のデータベースをつくってるOracleが世界最強ってコト?
13526/06/04(木)00:12:49No.1436441141+
我はicebergマン!
よくわからん!
13626/06/04(木)00:13:06No.1436441222+
ちょっとの操作ミスで全てがぶっ壊れたりしないexcelくれよ
accessはmacで使えないからダメ
13726/06/04(木)00:13:13No.1436441251+
>>ストアドプロシージャいいよね…
>数千行のストアドプロシージャいい…
>誰が使ってんだよこんなの
夜間バッチはそんなんばっかですよ…
13826/06/04(木)00:13:29No.1436441314そうだねx3
>一番使われてるDBはExcelだから最強のデータベースはExcelに決まってるだろ
面白いこと言うじゃねえの
帰れ帰れ
13926/06/04(木)00:13:39No.1436441366+
>SQLServerのソートってどういうルールなんだ?
>記号系は文字コードに従ってないような…
コレート見よう
14026/06/04(木)00:14:30No.1436441576+
>論理削除の代わりにステータスの変遷を記録するテーブルを作れってのは見たことある
>正しいのかどうかは知らん
利用用途によっては正しくはなる
14126/06/04(木)00:15:29No.1436441855+
会社に歴史が無いならなんだって出来るんですよ…!
14226/06/04(木)00:15:39No.1436441901+
>論理削除の代わりにステータスの変遷を記録するテーブルを作れってのは見たことある
うちにあるログテーブルじゃん
14326/06/04(木)00:16:06No.1436442025+
>論理削除の delete_flag を DB設計に入れるなって話が定期的にバズるけど
>現場の運用を考えると大変便利な小刀なのである
なんか二つできてるんスけど
14426/06/04(木)00:16:21No.1436442090+
>論理削除の代わりにステータスの変遷を記録するテーブルを作れってのは見たことある
>正しいのかどうかは知らん
ユーザーの状態に正常とか停止中とか退会済みとかがあるとして
ユーザーテーブルに列として持つと停止してからもう一回通常に戻ったときに前回いつ停止したかわからなくなるから別テーブルで管理しようねみたいな論
場合によるとしか・・・
14526/06/04(木)00:16:32No.1436442143+
>論理削除の代わりにステータスの変遷を記録するテーブルを作れってのは見たことある
>正しいのかどうかは知らん
論理削除が必要かは先ず検討が必要
マスタとかで過去のデータを参照する要件があって使うなら仕方ないけどそれは削除でなく有効期間を管理した方がいい
消したけど短期間なら戻せるようにしたいとかなら別に削除予約テーブルで管理して夜間バッチなどで物削した方がいい
14626/06/04(木)00:16:41No.1436442186そうだねx1
ぶっちゃけ今の状態が一番知りたいんだから変遷のログとは別にそれはそれで持ってた方が楽じゃね?
14726/06/04(木)00:17:17No.1436442332+
>場合によるとしか・・・
ネトフリとかどうなってんだろ…
14826/06/04(木)00:17:25No.1436442365+
まあマスター的なやつはUPDATE禁止DELETE禁止とかあったりするしな
14926/06/04(木)00:19:25No.1436442851+
論理削除無くて済むなら無い方がいいけどどのデータも有効期間が要るとも思えないし普通に使っていいと思う
15026/06/04(木)00:20:27No.1436443095+
実行計画正直全く読めなかったけどAIに丸投げすればなんとなく解説してくれるから助かる
15126/06/04(木)00:22:08No.1436443501+
>実行計画正直全く読めなかったけどAIに丸投げすればなんとなく解説してくれるから助かる
indexが効いてフルスキャンがなくてソートがでかいクエリにかかってなければいいよ
15226/06/04(木)00:22:08No.1436443502+
せめてflagって名前はやめてほしい…
15326/06/04(木)00:22:11No.1436443516+
実行計画読めない読む気がないDBエンジニアを見ると世界って割と適当に回ってんだなって思う
15426/06/04(木)00:22:43No.1436443648+
AIが流行り始めた頃「全てのデータをAIが把握するからDB言語どころかDB自体不要になる」って話を見たな
夢見させるようなことを言うな!!
15526/06/04(木)00:23:03No.1436443732+
DBエンジニアじゃなくても読んだりするのに…
15626/06/04(木)00:25:01No.1436444281そうだねx1
インフラエンジニアのピンキリ度は凄い
アプリエンジニアも幅はあるけどインフラの下限はどんなに詳しく書いても手順書通りにできない
15726/06/04(木)00:27:25No.1436444872+
sqlserver触ってるとぶちころしたくなるこのカス
Oracleに戻りたい
15826/06/04(木)00:29:18No.1436445312+
よくわからんけどAIに設計させれば良いDBが出来るんじゃないの
15926/06/04(木)00:30:14No.1436445544+
postgreSQLは参照系のショートカット豊富だし、設定もほぼクエリで確認できるし使いやすいぞ
ストアドもC,python,PL/SQLつかえるし
16026/06/04(木)00:31:04No.1436445774+
アプリエンジニアで凄いなと思ったのは子テーブルの定義に親テーブルID採用しなかった人がいた事
16126/06/04(木)00:31:21No.1436445865+
個別に納入する業務システムとかは相手との合意取れるならべき論はあんまり気にしなくても良い
他に移植するとかは知らん
16226/06/04(木)00:31:46No.1436445978+
なんかSQLServerがっていうよりGUIツールのSSMSが圧倒的に使いやすくない?
16326/06/04(木)00:31:48No.1436445991+
…子じゃないんじゃないか?
16426/06/04(木)00:32:04No.1436446061+
>アプリエンジニアで凄いなと思ったのは子テーブルの定義に親テーブルID採用しなかった人がいた事
えっ逆にそれでどうやってんの
16526/06/04(木)00:34:42No.1436446793+
データベーススペシャリスト取りたい
16626/06/04(木)00:35:41No.1436447061そうだねx3
>せめてflagって名前はやめてほしい…
わかりました
flgにします
16726/06/04(木)00:35:45No.1436447081+
みんなちゃんと正規化してる?
16826/06/04(木)00:35:58No.1436447151+
>flgにします
あほしね
16926/06/04(木)00:36:44No.1436447390+
>>flgにします
>あほしね
is_と_flg混在な弊社
17026/06/04(木)00:37:41No.1436447659+
csv!
json!
17126/06/04(木)00:38:02No.1436447764+
なんかもう帳票と一対一になるようなテーブルはカラム名もう日本語の方がいいんじゃねとか思ったりする
17226/06/04(木)00:38:43No.1436447980+
utf8の世の中になったしもう日本語でいいんじゃないかなとは思う
17326/06/04(木)00:39:25No.1436448192+
flgダメなとこあるんだ
17426/06/04(木)00:45:22No.1436449797+
名称は何でもいいけどスキーマ分けてくだち
17526/06/04(木)00:46:33No.1436450085+
論理削除で厄介なのはdelete日時が格納されてるされてないで判定させるやつ
17626/06/04(木)00:46:45No.1436450140+
まあフラグで論理削除使ってもいいけどパーティションにはしといてね…
削除データ増えると性能が悪くなら消してくれ
17726/06/04(木)00:47:22No.1436450304+
一時期マリアDBが来ると信じてました
17826/06/04(木)00:47:54No.1436450468+
>論理削除が必要かは先ず検討が必要
テーブルによって非表示って意味だったりマジで触れたらダメなデータだったり場合によってそのどっちかだったりするウチの悪口か?
17926/06/04(木)00:49:23No.1436450894+
NonSql君は最近どうなの
18026/06/04(木)00:50:01No.1436451055+
>えっ逆にそれでどうやってんの
そりゃ独自のサロゲートキーなんじゃ無い?
使ってるORM次第だと必須だったりするのまじクソ
18126/06/04(木)00:52:28No.1436451682+
MariaDBどうなったの

- GazouBBS + futaba-