09/01/21 19:51:11
リレーション具合にも夜から一概に言えない。
CSV読み込みで高速処理できるなら。トランザクションで一括処理すれば同程度には出来るかも。
そのへんはDBAのコンサルが詳しい。
201:デフォルトの名無しさん
09/01/23 02:04:57
＿人人人人人人人人人人人人人＿
＞ ビリビリしていってね！！！ ＜
,. .-――￣.^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^￣―. . ､
／: :r‐r============┐ ／´ / : :｀i､__ : : : ＼
/ : ├l‐１――― | ∧〉:/:/: : /: |= ミ丶、: :ヽ
/ : : : }‐ヒL二二二二二二｣ /: : :/l/ }:l:/l,: } ヽﾐi : :｜
|: : : :/:/: :/ |: :ｨ l :/:| ﾐ | {/ /ゝ､ﾉｲ ﾉl/ ／_ ﾄl!: : :|
|: : :/:/ :/--}/ |ﾉ}ハl-- ! } |l:/|/(ﾋ_] ﾋ_ﾝ ) ト. :｜
|: :/ｲrV (ﾋ_] ﾋ_ﾉ) |ﾉ| |/!:l '" ,＿___, "'' ﾉ: : |
|: : :八{ "" ""| :{ lﾊ. ヽ. _ﾝ / : :｜
}: :/:|:i ､ ― ﾉ ハ ノ}: iヽ、 .ｲ:i : : :{
ノイ}从{/ ＞ ＿＿ ィ::ﾉ :{ |:ハ: i｀. -----＜ﾄ:}从{:トヽ
202:デフォルトの名無しさん
09/01/23 23:52:23
>>197
public void addHoge(final List a)throws DataAccessException{
/* unDivide */
getSqlMapClientTemplate().execute(new SqlMapClientCallback() {
public Object doInSqlMapClient(SqlMapExecutor executor) throws SQLException {
Iterator it = a.iterator();
executor.startBatch();
while (it.hasNext()) {
String str = (String)it.next();
executor.insert("insert_sql", str);
}
int rowsaffected = executor.executeBatch();
return new Integer(rowsaffected);
}
});
}
これ以上はストアド化する他ないかな？
DBがOracleならストアド化しとけばいいんじゃない？
203:デフォルトの名無しさん
09/01/25 11:38:44
<(＾o＾)>
（ ） とうまー
／／
<(＾o＾)> とうまとうまー
（ ）
＼＼
..三 <(＾o＾)> とうまー
三 （ ）
三 ／／
. <(＾o＾)> 三 ねーとうまー
（ ） 三
＼＼ 三
204:あぼーん
あぼーん
あぼーん
205:あぼーん
あぼーん
あぼーん
206:デフォルトの名無しさん
09/01/29 19:52:08
ちょっと教えてもらいたいんだけど
整合性のとれていないDB（それがそもそも間違ってるんだが…）で
@ManyToOne の参照先エンティティが存在しなかった場合に
エンティティを自動的に生成するなりして例外を発生させない処理って
エンティティクラス内だけで実装可能？
207:デフォルトの名無しさん
09/01/30 01:00:03
>>206
回答になっているか分かりませんが。
URLﾘﾝｸ(72.14.235.132)
OTNのBBSがメンテ中なのでキャッシュから。
jpa 自動生成 エンティティ でググってみた。
ってか、JPAを使わないとダメなのかな？
iBATISならSQLとJavaBeanをマッピングすればおｋなのですが・・・。
208:デフォルトの名無しさん
09/01/30 03:53:45
整合性の取れてるまともなDBを作ってそっちをマスターにしたら？
今までの整合性無いDBへのリレーション維持の要求にはバッチ処理とかで旧システム互換取ればよくね？ リアルタイムでもいいけど。
209:デフォルトの名無しさん
09/01/30 14:15:38
>>206
そういう外部キー制約に関する整合性が取れてないDBと
JPAとの相性はすこぶる悪い
他のORM使った方がいいと思う
Hibernateの場合、一応例外を発生させないような設定オプションはあるけど
それでも、できるだけ採用しない方が無難
210:デフォルトの名無しさん
09/01/31 20:02:00
今ウチで保守をやってるシステムだと、
・各テーブルの末尾に「削除フラグ」列があって、
ここに 1 が入っている行はオンライン処理対象外とし、
日次夜間バッチでDELETEする
・マスタ系のテーブルやコード・区分テーブルには
「適用開始年月日」「適用終了年月日」列があって、
すでに無効になったデータも履歴として管理していて、
現在有効なデータを取得する条件として
「開始日 <= システム日付」かつ「終了日 >= システム日付」
を指定している
っていう処理があるのね。
で、こういう処理ってウチだけじゃなくて、他でもやってると思うんだけど、
そういった汎用的な処理を簡素化してくれる機能付きのO/Rマッパーって無いかな？
「特に指定しなければ、デフォルトで論理削除されてないデータのみを取得する」とか
「特に指定しなければ、デフォルトで現在有効なデータを取得する」とか、
O/Rマッパーが統一的に面倒見てくれると嬉しいんだけど、どうなんだろ？
それともそういうのって、O/Rマッピングを超えてるのかなぁ……
211:210訂正
09/01/31 20:02:47
誤：それともそういうのって、O/Rマッピングを超えてるのかなぁ……
正：それともそういうのって、「O/Rマッピング」の範疇を超えてるのかなぁ……
212:デフォルトの名無しさん
09/01/31 20:08:47
>>210
DBFluteってのがそこら辺の面倒みてくれたｷｶﾞｽ
213:デフォルトの名無しさん
09/01/31 20:31:59
>>210
COBOL系のシステムで見られる手法でRDBとは相性が悪いが、
底辺の現場で多く使われている。
たいていキーや関連が破綻している。
214:デフォルトの名無しさん
09/01/31 20:33:46
>>210
ウチはサマリの集計処理とか、要らないデータの削除処理がストアド(pl/pgSQL)で動いてますね。
基本はストアドで、それを1時間に1回、あるいは1ヶ月に1回バッチで呼び出す感じかな？
SpringFramework + iBATIS + PostgreSQL(pl/pgSQL)が一番保守しやすいっス。
他の処理も全部ストアド化しておけば良かったと後悔してますがね。orz
215:210
09/01/31 21:05:08
>>212 サンクス！
ドキュメントを斜め読みした限りでは良い感触かも。
ちょっとexampledb試してくる。
>>214 サンクス！
ウチのシステムはテーブル名に２バイト文字が使われてる等々、
>>213の言うとおりの残念設計だったのでiBatisがダメだったんだけど、
今見たら日本語通るようになってたので、ちょっと調べてみるよ。
ただ、どっちかというと、バッチよりオンライン処理の実装でラクをしたかったり。
10年以上改修を繰り返した結果、特にオン側のコードでスパゲティ化が著しいもんで……
216:デフォルトの名無しさん
09/02/01 02:17:50
メンテ用と本番用のフレームワークで分けて、遮蔽しとけば済む話では？
履歴系とリアルタイム系でシステム分けたい感じだが。
217:あぼーん
あぼーん
あぼーん
218:デフォルトの名無しさん
09/02/05 03:09:14
自分は iBatis はそこそこ経験があり、
Hibernate は、簡単なシステムで経験がある程度です（複雑なjoinが必要なかった)
今度 Spring + Hibernate + JPA のサンプルを作ることになり、
URLﾘﾝｸ(www.amazon.co.jp)
の本を見ながらやりはじめました。
この本の P.87 を見ると「EntityManager に更新に相当するメソッドはない」とありますが、
JPA でレコードを更新するときは、必ず一度 select しておかないといけないのでしょうか？
DB を更新する際に、一度 select せず、いきなり update 文で一括更新したいこととかあると思いますが、
----------------------------
例：
年度の締め処理において、「契約状態フラグ = "契約済み"」 となっているレコードを「締め済みフラグ = "締め済み"」にする。
SQL の例：
update 契約情報 set 締め済みフラグ = '締め済み'
where 契約状態フラグ = '契約済み'
----------------------------
219:218
09/02/05 03:10:16
(続き)
こういう場合は、以下の3択でしょうか(他にあれば指摘してください）
(1)対象データを全部 select してきて、for 文でエンティティに更新したい値をセットして反映させる
(2)JPQLか、
(3)ネイティブQuery
(1)だと大量データの時にパフォーマンスで問題がありそう。
(3)のネイティブQuery だと、JPA が持っているキャッシュとDBのズレが生じるというデメリットがある
とどこかで読んだのですが、この認識はあってますか？
(2)のJPQLだと、ネイティブQuery と同じように集合演算的に扱え、かつ JPA が持っているキャッシュと同期がとれると理解しています。
SQL を避けるために O/R マッパーを使っているのに、String で SQL モドキの言語を生成するのはイヤですが・・・
結局 データを集合的に扱いたければ、JPA や Hibernate のような O/R マッパは向かない、ということになるのかな。
220:デフォルトの名無しさん
09/02/05 03:19:44
JPQL使ってもキャッシュと同期は保証されない
ただし自分でEntityManager#flush()することができる
221:デフォルトの名無しさん
09/02/05 03:22:53
while(1)
{
wakeup;
static int day;
int time = wakeuptime();
while(1)
{
2ch;
if(time == Daytime())
{
lunch;
};
if(time == nighttime())
{
supper;
};
if( time == sleeptime();)
{
break;
}
time++;
}
day++;
sleep;
}
こんな毎日、無限ループって怖いよな；；
222:デフォルトの名無しさん
09/02/08 21:21:22
>>221
なんか1日が終わらない気がするけどどうでもいいや
223:デフォルトの名無しさん
09/02/09 10:27:02
EclipseLink関連のドキュメントで良い奴ありますか？
公式のExampleが1.0.2で動かないので、1.0.1で試してみたら動く、とか、
適当も良いところなんですが。。。
224:デフォルトの名無しさん
09/02/14 11:55:06
EclipseLink 1.1ってなかなか出ないね
225:デフォルトの名無しさん
09/03/12 16:53:18
EclipseLink 1.1age
226:デフォルトの名無しさん
09/03/28 21:54:49
EclipseLink新ロゴ
URLﾘﾝｸ(www.eclipse.org)
227:デフォルトの名無しさん
09/03/31 04:40:35
PreparedStatementのキャッシュをコネクションを超えてプール出来ないものかねぇ。
DB側ではセッションとかも浪費してると思うと何だかね。（俺の知識が古い？）
JDBCにPreparedStatementの構文でストアド登録できる機能みたいなのが欲しい。
まあこんな機能はチラシの裏すぎるとは思うが。