■SI Object Browser 掲示板
|
ユーザの皆様、開発者、サポート担当者の交流のための掲示板です！ ユーザーの皆様同士で教え合ったりもできる交流の場にしたいと思っていますので、相互協力をよろしくお願いします。 なお、過去に同じようなQ&Aがあるケースも多いので、投稿前にキーワード検索してみてください。 |
 |
| ※各投稿のカラーは対象となる製品に対応しています。【■…OB ■…OBER ■…全般 ■…その他】 ※ライセンスに関するお問合せにつきましては、お問い合わせページよりご連絡いただきますようお願いいたします。 ※誹謗中傷や公序良俗に反する書き込みはご遠慮ください。運営側の判断によりメッセージを削除する場合があります。 ※環境依存や技術的調査が必要な問題については掲示板上ではお答えしかねます。ご了承ください。 | |
OBERの他データーベース対応
2002/07/04 17:01
OBER
4
沢渡 みかげ
純粋なER図ツールを探していて，OBERを試用させて頂いたのですが，
なかなか使い勝手がよさそうな感じです．
ターゲットのDBはOracleでは無くMySQLなのですが，(^^;
型の定義を行うとER図作成ツールとしてはなんとか使えるようです．
ENUM，SET 部分の扱いが出来ない，とか，INDEXの構文が異なる
（BLOB等に張るときはサイズ指定が必要とか）MySQL独自の部分は
やはりうまくいかず，SQL出力はスクリプト等でいったん変換
しないと使えなさそうなのが残念なところではあるのですが‥‥‥
ふと掲示板を見たら，Oracle以外のRDBMSにも対応したいという
書き込みがあったので，今後に期待しています．
個人的には，フォワードのみでも構わないので，対応希望を
表明しておきます．
MySQL はユーザーもかなりいると思いますが，DB上でリレーションを
管理できないので，ER図があるとかなり開発がやりやすくなります．
（そういう意味でも，リバース対応が完成しても使い勝手は微妙ですね(^^;）
他，１点気になったのが，プリント出力すると陰やボールド表示が
消えてしまうようです．
画面表示の美しさのまま，プリント出力できると嬉しいですね．
なかなか使い勝手がよさそうな感じです．
ターゲットのDBはOracleでは無くMySQLなのですが，(^^;
型の定義を行うとER図作成ツールとしてはなんとか使えるようです．
ENUM，SET 部分の扱いが出来ない，とか，INDEXの構文が異なる
（BLOB等に張るときはサイズ指定が必要とか）MySQL独自の部分は
やはりうまくいかず，SQL出力はスクリプト等でいったん変換
しないと使えなさそうなのが残念なところではあるのですが‥‥‥
ふと掲示板を見たら，Oracle以外のRDBMSにも対応したいという
書き込みがあったので，今後に期待しています．
個人的には，フォワードのみでも構わないので，対応希望を
表明しておきます．
MySQL はユーザーもかなりいると思いますが，DB上でリレーションを
管理できないので，ER図があるとかなり開発がやりやすくなります．
（そういう意味でも，リバース対応が完成しても使い勝手は微妙ですね(^^;）
他，１点気になったのが，プリント出力すると陰やボールド表示が
消えてしまうようです．
画面表示の美しさのまま，プリント出力できると嬉しいですね．
返信を投稿
OBER
梅田＠SI
こんにちは、OBERのご試用ありがとうございます。
>純粋なER図ツールを探していて，
これは実にOBERのコンセプトにマッチする言葉で嬉しいです。
>ターゲットのDBはOracleでは無くMySQLなのですが，
なんと、今度はMySQLですか？
最近「日経ソフトウェア7月号」の特集記事を書く際に
MySQLを使ってみたのですが、シンプルでなかなか良かったですね。
>ふと掲示板を見たら，Oracle以外のRDBMSにも対応したいという
>書き込みがあったので，今後に期待しています．
>個人的には，フォワードのみでも構わないので，対応希望を
>表明しておきます．
なるほど。フォワードだけならさまざまなデータベース対応という
考え方も有りえそうですね。参考にさせていただきます。
>他，１点気になったのが，プリント出力すると陰やボールド表示が
>消えてしまうようです．
>画面表示の美しさのまま，プリント出力できると嬉しいですね．
これも、検討課題として承りました。
ありがとうございます。
>純粋なER図ツールを探していて，
これは実にOBERのコンセプトにマッチする言葉で嬉しいです。
>ターゲットのDBはOracleでは無くMySQLなのですが，
なんと、今度はMySQLですか？
最近「日経ソフトウェア7月号」の特集記事を書く際に
MySQLを使ってみたのですが、シンプルでなかなか良かったですね。
>ふと掲示板を見たら，Oracle以外のRDBMSにも対応したいという
>書き込みがあったので，今後に期待しています．
>個人的には，フォワードのみでも構わないので，対応希望を
>表明しておきます．
なるほど。フォワードだけならさまざまなデータベース対応という
考え方も有りえそうですね。参考にさせていただきます。
>他，１点気になったのが，プリント出力すると陰やボールド表示が
>消えてしまうようです．
>画面表示の美しさのまま，プリント出力できると嬉しいですね．
これも、検討課題として承りました。
ありがとうございます。
返信を投稿
OBER
MySQL 用として実用になるかどうか引き続き試用中です．
データ型をMySQL用にし，ENUM，SET等はデフォルト値の
ところに定義を入れ，最後に出力したスクリプトを
変換するという方法で，なんとかなりそうな感じです．
>>ターゲットのDBはOracleでは無くMySQLなのですが，
>なんと、今度はMySQLですか？
>最近「日経ソフトウェア7月号」の特集記事を書く際に
>MySQLを使ってみたのですが、シンプルでなかなか良かったですね。
コストが安いこと（28000円），高速であること（単純な
処理ならOracleの100倍は速いと思います），などの
利点があるので，最近わりとよく使用しています．
コストと，MySQLのメリット，デメリット（トランザクションや
障害時の確実なデータ保護出来ない）をお客さんに
提示すると，弊社のお客様ではほとんどMySQLの方を選択されます．
%小～中規模なサイト構築が多いので‥‥‥
他，色々いじっていたのですが，いくつか報告と要望を．．．
・UNDO/REDO機能が欲しいです．削除するエンティティを間違えたり
したとき，UNDO出来ないのはかなり不便に感じました．
・エンティティ編集画面で，インデックスタブを選択し，
インデックスタイプで主キーを選ぶと「主キーは選択できません」
というダイアログがでます．
Okを押して閉じて，終了ボタンをクリック，「情報が変更
されています．保存しますか？」でいいえを選ぶと，
エラーでダイアログが閉じるようです．
また，ここではいを選ぶと，「主キーは選択できません」
のダイアログがでて，閉じても再び出てきて操作が
続けられなくなるようです．
（ダイアログを閉じてすぐに他のインデックスタイプを選べば
なんとか復帰可能のようです．）
また，上記の操作を行ったりして色々いじっていたら，
読み込むとOBERが落ちるファイルが出来てしまいました．
（必要でしたらこのファイルをお送りします．）
・フォワードエンジニアリングで，SQL出力をすると，
オプションのDROP文を出力するを選択していても，
出力されないようです．
プレビューしてから，SQL出力を選ぶと，
正常に出力されました．
では，よろしくお願いします．
データ型をMySQL用にし，ENUM，SET等はデフォルト値の
ところに定義を入れ，最後に出力したスクリプトを
変換するという方法で，なんとかなりそうな感じです．
>>ターゲットのDBはOracleでは無くMySQLなのですが，
>なんと、今度はMySQLですか？
>最近「日経ソフトウェア7月号」の特集記事を書く際に
>MySQLを使ってみたのですが、シンプルでなかなか良かったですね。
コストが安いこと（28000円），高速であること（単純な
処理ならOracleの100倍は速いと思います），などの
利点があるので，最近わりとよく使用しています．
コストと，MySQLのメリット，デメリット（トランザクションや
障害時の確実なデータ保護出来ない）をお客さんに
提示すると，弊社のお客様ではほとんどMySQLの方を選択されます．
%小～中規模なサイト構築が多いので‥‥‥
他，色々いじっていたのですが，いくつか報告と要望を．．．
・UNDO/REDO機能が欲しいです．削除するエンティティを間違えたり
したとき，UNDO出来ないのはかなり不便に感じました．
・エンティティ編集画面で，インデックスタブを選択し，
インデックスタイプで主キーを選ぶと「主キーは選択できません」
というダイアログがでます．
Okを押して閉じて，終了ボタンをクリック，「情報が変更
されています．保存しますか？」でいいえを選ぶと，
エラーでダイアログが閉じるようです．
また，ここではいを選ぶと，「主キーは選択できません」
のダイアログがでて，閉じても再び出てきて操作が
続けられなくなるようです．
（ダイアログを閉じてすぐに他のインデックスタイプを選べば
なんとか復帰可能のようです．）
また，上記の操作を行ったりして色々いじっていたら，
読み込むとOBERが落ちるファイルが出来てしまいました．
（必要でしたらこのファイルをお送りします．）
・フォワードエンジニアリングで，SQL出力をすると，
オプションのDROP文を出力するを選択していても，
出力されないようです．
プレビューしてから，SQL出力を選ぶと，
正常に出力されました．
では，よろしくお願いします．
返信を投稿
OBER
初音玲
すいません、OBERのことじゃないです。
[沢渡 みかげ]
>コストと，MySQLのメリット，デメリット（トランザクションや
>障害時の確実なデータ保護出来ない）をお客さんに
>提示すると，弊社のお客様ではほとんどMySQLの方を選択されます．
そのデメリットは「RDBMSではない」というのと一緒なので、
RDBMSでないものとRDBMSを同じ土俵で比べてしまうのがどう
かと思います。
RDBMSを入れる程ではない信頼性のシステムであれば、余計な
機能はとっぱらってしまって速度が速いに越した事はないです
ね。
>%小～中規模なサイト構築が多いので‥‥‥
RDBMSにするかしないかは、規模ではなくて信頼性です。
そういった規模のサイトでも、一度でも障害が発生してデータ
をロストしてしまってから、RDBMSレベルの信頼性が必要な事
をお客様自身も理解するなんて事も実際問題ありますからね。
# OBともOBERとの直接関係ないデータベースの話ですが、老婆
# 心から返信させて頂きました。
# システム構築時にどこで線引きをするかは、奥が深い話題で
# もあるので、
# http://www.sint.co.jp/bbs/index.asp
# で話を続けるのもありかも知れませんね。
[沢渡 みかげ]
>コストと，MySQLのメリット，デメリット（トランザクションや
>障害時の確実なデータ保護出来ない）をお客さんに
>提示すると，弊社のお客様ではほとんどMySQLの方を選択されます．
そのデメリットは「RDBMSではない」というのと一緒なので、
RDBMSでないものとRDBMSを同じ土俵で比べてしまうのがどう
かと思います。
RDBMSを入れる程ではない信頼性のシステムであれば、余計な
機能はとっぱらってしまって速度が速いに越した事はないです
ね。
>%小～中規模なサイト構築が多いので‥‥‥
RDBMSにするかしないかは、規模ではなくて信頼性です。
そういった規模のサイトでも、一度でも障害が発生してデータ
をロストしてしまってから、RDBMSレベルの信頼性が必要な事
をお客様自身も理解するなんて事も実際問題ありますからね。
# OBともOBERとの直接関係ないデータベースの話ですが、老婆
# 心から返信させて頂きました。
# システム構築時にどこで線引きをするかは、奥が深い話題で
# もあるので、
# http://www.sint.co.jp/bbs/index.asp
# で話を続けるのもありかも知れませんね。
返信を投稿
OBER
沢渡 みかげ
脇道レス続けてしまってすいません．
>そのデメリットは「RDBMSではない」というのと一緒なので、
>RDBMSでないものとRDBMSを同じ土俵で比べてしまうのがどう
>かと思います。
技術的な視点からみれば，確かにそうではあるのですが，
お客様からの視点では同じ土俵になってしまうでしょうね．
クラッシュしたら前日のバックアップまで戻ってしまう，
というような形の運用でも問題ないとされるお客様もいます．
% Web関係で，非ショッピング系（コミュニティ等）
% の構築が多いという弊社の特徴の為でもあると思いますが．．．
>RDBMSにするかしないかは、規模ではなくて信頼性です。
>そういった規模のサイトでも、一度でも障害が発生してデータ
>をロストしてしまってから、RDBMSレベルの信頼性が必要な事
>をお客様自身も理解するなんて事も実際問題ありますからね。
以前ロストしたこともありましたが，それでもMySQLで，
というお客様もいたりします．
この辺は，データの重要度の認識の違いかもしれません．
一般的なショッピングサイト等では許されないことでしょうから，
普段手がけているものが少し特殊なのかもしれません．(^^;
特に，予算に関してはやはりかなり重要度が高いようですので‥‥‥．
（PostgreSQLといったような選択肢も有りだとは思いますが，
これで過去何度かデータロストをしているので最近怖くて
使用していなかったりします．）
一般的なERツールは予算的な問題でこれまで見送ってきたのですが，
OBERの登場でその辺が変わりそうな感じはしますね．
５０万と１０万以下ではだいぶかわりますし．
>そのデメリットは「RDBMSではない」というのと一緒なので、
>RDBMSでないものとRDBMSを同じ土俵で比べてしまうのがどう
>かと思います。
技術的な視点からみれば，確かにそうではあるのですが，
お客様からの視点では同じ土俵になってしまうでしょうね．
クラッシュしたら前日のバックアップまで戻ってしまう，
というような形の運用でも問題ないとされるお客様もいます．
% Web関係で，非ショッピング系（コミュニティ等）
% の構築が多いという弊社の特徴の為でもあると思いますが．．．
>RDBMSにするかしないかは、規模ではなくて信頼性です。
>そういった規模のサイトでも、一度でも障害が発生してデータ
>をロストしてしまってから、RDBMSレベルの信頼性が必要な事
>をお客様自身も理解するなんて事も実際問題ありますからね。
以前ロストしたこともありましたが，それでもMySQLで，
というお客様もいたりします．
この辺は，データの重要度の認識の違いかもしれません．
一般的なショッピングサイト等では許されないことでしょうから，
普段手がけているものが少し特殊なのかもしれません．(^^;
特に，予算に関してはやはりかなり重要度が高いようですので‥‥‥．
（PostgreSQLといったような選択肢も有りだとは思いますが，
これで過去何度かデータロストをしているので最近怖くて
使用していなかったりします．）
一般的なERツールは予算的な問題でこれまで見送ってきたのですが，
OBERの登場でその辺が変わりそうな感じはしますね．
５０万と１０万以下ではだいぶかわりますし．
返信を投稿
OBER