Ｐｕ
- 合計アクティビティ 409
- 前回のアクティビティ
- メンバー登録日
- フォロー 0ユーザー
- フォロワー 0ユーザー
- 投票 0
- サブスクリプション 121
コメント
Ｐｕによる最近のアクティビティ-
こんんちはPuです 物理的に印刷すると言う固定概念を変えない限り（生産性向上も含め）難しいでしょうね。 お客様に送付するOUTPUT関係はpdfで出力しmailで送信 社内資料等のOUTPUTはEXCEL出力などにして送信か共有フォルダに配置など 昔のオフコンの考え方を実現するのではなくWEB系の考え方を取り入れないと 時代遅れになるのでしょうね。って自分に言い聞かせてます。(笑) でわ～でわ～
-
こんんちはPuです Dockerググって下さい（笑 RIAならそんなにメモリーを必要としませんので大丈夫だと思います RDPは結構メモリー必要ですので64GBで50台は悩みどころですね 最近私はDBサーバーのdiskはSSDにしています。 でわ～でわ～
-
こんんちはPuです クラサバ20~30台でも処理はクラアントで行うので問題ないかと（DBサーバー高速なスペック１台） リモートAPP用サーバーを15台位で１台の割合で複数台配置したら大丈夫かと 後はアベイラビリティをどこまで高めるかで構成が変わるのでは WindowsはDockerが使えないので．．．ハード構成でアベイラビリティを高める方が楽かな でわ～でわ～
-
こんんちはPuです ２枚差しを使用する場合の目的にもよります １）速度向上を目的とする場合：nicチーミング ２）アベイラビリティを高める場合：仮想nic ３）ルーティングする場合：別サブネットでルーティングテーブル作成 思いつくのはそれぐらいかと でわ～でわ～
-
こんにちはＰｕです トランザクションとロックを誤解されていませんか？ 前も同じような投稿があったような．．． トランザクションは一取引単位でその取引単位で整合性を取る為その取引単位でロックが必要なんです。 あくまでもトランザクション（一取引）で整合性を取る事が重要で その為、出来るだけロック時間を短くする工夫（楽観的ロック）があるわけで ですので取引が失敗した時、どの時点に戻せば整合性がとれ...
-
こんにちはＰｕです。 nkmtさん、なにか話の根幹がずれて来てるような 前も遅延トラン（magicの世界の言葉：一般的には楽観的ロック）の話がありました。 データベースのロックを出来るだけ発生させない仕組みですよ。 ｗｅｂの世界では画面を開きっぱなし、かつ大量のユーザーがアクセスするので 従来のようなトランザクションロックではロックされる確率が高いので 楽観的ロックと言う手法が出てきたのです...
-
こんにちはＰｕです 一旦メモリーワークで入力し、その後実テーブルに書き出すと言う動作は 遅延トランとほぼ同じ動作ですよ。（データセットが同じ仕組みなので） ただ競合の仕組みを自前で組み込まないといけませんが 遅延トランはそのような仕組みをメモリーワークを使わなくてもできる（内部的にはメモリーワークを使用している） 遅延トランは競合の仕組みをレコード単位、項目単位と細かな設定がノンプログラミン...
-
そのうち サーバーレスで フロントはjavascriptのフレームで バックはAWS LamdaかGoogle Cloud Functionでの開発が主流になるのでしょうね Chromeのデバッガーもっと使いこなす用にならないと でわ～でわ～
-
こんにちはＰｕです web関係の仕事もが多いので、Web Client試さないとと思いつつ ついつい慣れているBootstrap+Jqueryで作ってしまいます。（ライセンスいらないので^^） chromeのデバッガーが優秀すぎて．．． でわ～でわ～
-
こんにちはＰｕです 過去の経験からのレスですのであしからず。 結果データベースには、Memoryを指定しています。 他の選択で上手くいかなかった事があったので。 それとよっぽどのことがない限りビューの定義はしません データが少ない時はビューも有効ですが、売上headとitemなど件数の多いのを ビュー定義すると、ビューを開くたびに遅いです。 microsoft dynamicsなどのパッケー...