私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレMySQL 総合 Part23
mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
データによるとしか
まあ多く見積もって50万レコード/年くらいだろうから、
単純に入れるだけなら1年1テーブルくらいでよいのでは?
まあ多く見積もって50万レコード/年くらいだろうから、
単純に入れるだけなら1年1テーブルくらいでよいのでは?
犯罪者個人に対して告訴状を違法派遣・偽装請負・偽装出向・多重派遣の被害者が作成(刑事告訴は無料) or 司法書士が代筆(料金は5万円ぐらい)※コピペ歓迎
↓
告訴状を【検察の直告班】に郵便局の内容証明付で送付(疎明資料・証拠にはICレコーダー、スマホによる録音が適しています)
↓
審査 → 不受理 → 告訴状再提出または刑法 第193条で訴えを起こす
↓
受理 → 告訴事実を認め示談交渉(↓) →示談成立 → 法廷相場50~100万円の示談金 ※示談拒否が良い
↓ ↓
事案化← 前科あり ←示談不成立(↓)→ 示談外交渉→ 犯罪者の年収半額×最大懲役年数の和解金支払い※推奨
↓ ↓
↓ 起訴 →公判 → 罰金刑=前科(起訴事実を認めてるため)→追討ち民事訴訟
↓
審査 → 起訴(強制捜査・留置場)→ 公判 → 懲役刑などの厳罰(反省が認められないため)→追討ち民事訴訟
↓
不起訴、起訴猶予
↓
検察審査会法第30条(検察審査会へ申し立て)→ 起訴 → 起訴後は同上
刑法 第193条(公務員職権濫用)で検察事務官を刑事告訴 → 同上
◎告訴→告訴受理→示談交渉→厳罰を求め示談不成立→示談外交渉→和解金支払い・和解契約(公正証書・即決和解で秘密保持契約)
◎偽装請負・出向・違法派遣事件では派遣・出向先両方の代表者、役員、現場責任者に告訴できます。
前科がついた犯罪者が法人の代表であれば公的な入札からの排除、取引先や顧客との契約解除など社会的制裁・批判に晒されることから辞職または解任が妥当、役員・社員であれば懲戒を想定。
◎事業者内部の加害関係者による刑事告発(刑事訴訟法239条1項)も可能です。
加害者本人、管理間接部門の社員が刑事告発に踏み切る場合も和解金による解決が妥当です。
注意:告訴が受理されない理由
●3年間(※)の時効が過ぎたもの ※違法派遣
●同一事実について過去に告訴取消しがあったもの
●関連する民事訴訟を有利に導く目的の場合
●証拠が希薄なもの ※被害者が契約時に違法派遣・偽装請負・多重派遣と知っていても刑事告訴は有効です。
↓
告訴状を【検察の直告班】に郵便局の内容証明付で送付(疎明資料・証拠にはICレコーダー、スマホによる録音が適しています)
↓
審査 → 不受理 → 告訴状再提出または刑法 第193条で訴えを起こす
↓
受理 → 告訴事実を認め示談交渉(↓) →示談成立 → 法廷相場50~100万円の示談金 ※示談拒否が良い
↓ ↓
事案化← 前科あり ←示談不成立(↓)→ 示談外交渉→ 犯罪者の年収半額×最大懲役年数の和解金支払い※推奨
↓ ↓
↓ 起訴 →公判 → 罰金刑=前科(起訴事実を認めてるため)→追討ち民事訴訟
↓
審査 → 起訴(強制捜査・留置場)→ 公判 → 懲役刑などの厳罰(反省が認められないため)→追討ち民事訴訟
↓
不起訴、起訴猶予
↓
検察審査会法第30条(検察審査会へ申し立て)→ 起訴 → 起訴後は同上
刑法 第193条(公務員職権濫用)で検察事務官を刑事告訴 → 同上
◎告訴→告訴受理→示談交渉→厳罰を求め示談不成立→示談外交渉→和解金支払い・和解契約(公正証書・即決和解で秘密保持契約)
◎偽装請負・出向・違法派遣事件では派遣・出向先両方の代表者、役員、現場責任者に告訴できます。
前科がついた犯罪者が法人の代表であれば公的な入札からの排除、取引先や顧客との契約解除など社会的制裁・批判に晒されることから辞職または解任が妥当、役員・社員であれば懲戒を想定。
◎事業者内部の加害関係者による刑事告発(刑事訴訟法239条1項)も可能です。
加害者本人、管理間接部門の社員が刑事告発に踏み切る場合も和解金による解決が妥当です。
注意:告訴が受理されない理由
●3年間(※)の時効が過ぎたもの ※違法派遣
●同一事実について過去に告訴取消しがあったもの
●関連する民事訴訟を有利に導く目的の場合
●証拠が希薄なもの ※被害者が契約時に違法派遣・偽装請負・多重派遣と知っていても刑事告訴は有効です。
>毎日テーブルを一つ作成していくのと
少し考えただけで、テーブルの管理がすっげー面倒になると思わんけ?
少し考えただけで、テーブルの管理がすっげー面倒になると思わんけ?
質問です。
DATETIME型をWHERE句に入れる場合、
LIKEを使うとINDEXが使われずにとても遅いので、BETWEENを使いましょう
というのは有名な話だと思いますが、これはDATE型でも言えることですか?
DATE型でもBETWEENを使った方がINDEXが使われて早い検索ができますか?
DATETIME型をWHERE句に入れる場合、
LIKEを使うとINDEXが使われずにとても遅いので、BETWEENを使いましょう
というのは有名な話だと思いますが、これはDATE型でも言えることですか?
DATE型でもBETWEENを使った方がINDEXが使われて早い検索ができますか?
>>354
テーブルの管理をするためのテーブルを(ry
テーブルの管理をするためのテーブルを(ry
カラムの数とか可変長のカラムが多い少ないとか
100カラムとかあったらたいへんでは
実際に管理しているデータベースで1600万行、データサイズ2.7GBのテーブルあるけど快適動作
100カラムとかあったらたいへんでは
実際に管理しているデータベースで1600万行、データサイズ2.7GBのテーブルあるけど快適動作
※コピペ歓迎です。
違法派遣(偽装請負・多重派遣・偽装出向・事前面接等)についての刑事罰
【告訴権者=業務委託、準委任、共同受注、業務請負契約および特定派遣(契約・正規)、一般派遣、正規社員】
①職業安定法第44条の労働者供給事業の禁止規定に違反(1年以下の懲役または20万円以下の罰金)
■偽装請負・多重派遣・偽装出向・多重出向
■事前面接(顔合わせ・面談・職場見学等)と履歴書・職務経歴書・スキルシート等提出による労働者の特定(※)
(音声録音で立証可能)
②労働基準法第6条(中間搾取の禁止) (1年以下の懲役又は50万円以下の罰金)
■多重派遣・多重出向
※違法派遣(派遣労働者の特定)→派遣法で認められた派遣労働者ではない→労働者供給事業→職業安定法44条違反というの
が前提となる法解釈となります。派遣法における罰則が軽微なのは法律の不備や労働者軽視などが原因ではありません。
違法派遣は全て職業安定法44条で裁くことが可能なため、刑罰の重複を避けるために派遣法には軽微な罰則(主に裁量行政による)しかないのです。
使用者に有利な民事訴訟や労働関係諸局への通報等の対極にあるのが書面(告訴状)による刑事告訴(※告訴先は検察の直告班)です。
労働関係諸局への通報・斡旋による軽微な「適正化」や監督・指導に対して、法律に定められた刑事罰を問うことになり、
違法派遣業者にとって有罪は考えられる限り最大の処罰となります。同時に刑事罰を受けた
担当者が取引先に与える悪印象を考慮すれば、通常会社側は告訴が受理された時点で告訴取り下げに
動くのが妥当でしょう。懲役、前科がつく刑罰が下される可能性から、告訴取り下げの和解金は高額となることが多いのです。
告訴の流れとしては、
刑事告訴⇒告訴受理⇒告訴取下げ要請⇒取下げ和解金入金⇒告訴取下げ
となります。告訴の懲役刑適応は犯罪者個人に対してのみですので、告訴する対象は
派遣先・派遣元 社長
派遣先・派遣元 責任者・管理役員・取締役
派遣先・派遣元 人事管理担当者・人事管理役員・取締役
が妥当です。刑事告訴取り下げの和解金額は犯罪者個人と交渉するとよいでしょう。(告訴状は人数分提出する必要あり)
違法派遣(偽装請負・多重派遣・偽装出向・事前面接等)についての刑事罰
【告訴権者=業務委託、準委任、共同受注、業務請負契約および特定派遣(契約・正規)、一般派遣、正規社員】
①職業安定法第44条の労働者供給事業の禁止規定に違反(1年以下の懲役または20万円以下の罰金)
■偽装請負・多重派遣・偽装出向・多重出向
■事前面接(顔合わせ・面談・職場見学等)と履歴書・職務経歴書・スキルシート等提出による労働者の特定(※)
(音声録音で立証可能)
②労働基準法第6条(中間搾取の禁止) (1年以下の懲役又は50万円以下の罰金)
■多重派遣・多重出向
※違法派遣(派遣労働者の特定)→派遣法で認められた派遣労働者ではない→労働者供給事業→職業安定法44条違反というの
が前提となる法解釈となります。派遣法における罰則が軽微なのは法律の不備や労働者軽視などが原因ではありません。
違法派遣は全て職業安定法44条で裁くことが可能なため、刑罰の重複を避けるために派遣法には軽微な罰則(主に裁量行政による)しかないのです。
使用者に有利な民事訴訟や労働関係諸局への通報等の対極にあるのが書面(告訴状)による刑事告訴(※告訴先は検察の直告班)です。
労働関係諸局への通報・斡旋による軽微な「適正化」や監督・指導に対して、法律に定められた刑事罰を問うことになり、
違法派遣業者にとって有罪は考えられる限り最大の処罰となります。同時に刑事罰を受けた
担当者が取引先に与える悪印象を考慮すれば、通常会社側は告訴が受理された時点で告訴取り下げに
動くのが妥当でしょう。懲役、前科がつく刑罰が下される可能性から、告訴取り下げの和解金は高額となることが多いのです。
告訴の流れとしては、
刑事告訴⇒告訴受理⇒告訴取下げ要請⇒取下げ和解金入金⇒告訴取下げ
となります。告訴の懲役刑適応は犯罪者個人に対してのみですので、告訴する対象は
派遣先・派遣元 社長
派遣先・派遣元 責任者・管理役員・取締役
派遣先・派遣元 人事管理担当者・人事管理役員・取締役
が妥当です。刑事告訴取り下げの和解金額は犯罪者個人と交渉するとよいでしょう。(告訴状は人数分提出する必要あり)
5.6っていつ出んの?
リリースサイクル、全然守られてねえし、
バージョン上がってもマイナーチェンジくらいだし。
Oracleはやる気あんの?
リリースサイクル、全然守られてねえし、
バージョン上がってもマイナーチェンジくらいだし。
Oracleはやる気あんの?
mysqlを業務で使ってる所ってバックアップは何か専用のツールを使ってるんですか?
それともやっぱりmysqldumpで?
それともやっぱりmysqldumpで?
どのタイミングのバックアップ?
うちは日次はファイルシステムのスナップショットとるだけ
うちは日次はファイルシステムのスナップショットとるだけ
あ、フルバックアップなんかはどうしてるんですか?
パワハラ犯罪にたいする刑事罰(※本投稿のコピペ歓迎です)
人事原則
1 現行法では、社員が仕事を怠けたり、能力不足、就業規則違反、目標を達成できなくても解雇をしたり叱責することは違法です。どんな駄目社員、嘘つき社員、怠け者も定年まで解雇が違法なのが現行の正社員制度です。
2 パワハラは社風にあわない社員、成績の振るわない社員を自主退職に追い込む言わば人事的措置として用いられることが多い。
※違法な解雇の和解金相場は、労働審判で3ヶ月、通常裁判で1年以上の報酬、さらに社員が和解を拒めば復職が可能です。弁護士への着手金は12~15万円、和解拒否なら20~50万円程度。
人事部・ホットライン・御用組合へ直訴
メリット: 一時的緩和や人事異動
デメリット: 役員へ情報筒抜け、危険分子の烙印(情報漏洩がホットライン直訴者に多いのは人事部の常識)、パワハラ放置で自主退職に追い込まれる
民事訴訟・調停・労働審判
メリット: 損害賠償
デメリット: 裁判費用、解雇措置、民事不介入で刑事事案化を阻止、長期係争、パワハラ上司の継続雇用
刑事告訴
メリット: 1パワハラ上司の解雇・懲戒、または2多額の和解金、1と2どちらでも被害者の雇用は維持
デメリット: 人事異動(出世コースから外れる)
◎録音は一方の当事者が取る限り合法です。※加害者に録音の同意を求める必要はありません。
◎告訴受理後の和解金は加害者の資産・収入に応じて変えてください。犯罪者の昨年の年収の半額程度×最大懲役年数が妥当です。
◎パワハラの被害についての告訴は1侮辱罪2脅迫罪3強要罪4威力業務妨害罪5傷害罪の順序で行ってください。警察・検察の協力(犯罪者の自宅・職場の強制捜査、留置所勾留)により罪の立証が楽になります。
◎刑事告訴した社員を解雇したり処遇面で著しい差別を行うことはないでしょうが、出世や管理職以上の昇進の可能性はあきらめるべきでしょう。
◎刑事告訴は民事訴訟と違って裁判による被害者への2次被害にありません。検察庁が被害者に代わって訴えをおこすので、無料で、時間と手間も告訴状をかくことと音声録音を残すだけです。
◎和解契約(公正証書・即決和解)では告訴した事実は秘匿事項となります。犯罪者が秘密保持契約を違反した場合の損害賠償金は、最低5000万円~にしましょう。
人事原則
1 現行法では、社員が仕事を怠けたり、能力不足、就業規則違反、目標を達成できなくても解雇をしたり叱責することは違法です。どんな駄目社員、嘘つき社員、怠け者も定年まで解雇が違法なのが現行の正社員制度です。
2 パワハラは社風にあわない社員、成績の振るわない社員を自主退職に追い込む言わば人事的措置として用いられることが多い。
※違法な解雇の和解金相場は、労働審判で3ヶ月、通常裁判で1年以上の報酬、さらに社員が和解を拒めば復職が可能です。弁護士への着手金は12~15万円、和解拒否なら20~50万円程度。
人事部・ホットライン・御用組合へ直訴
メリット: 一時的緩和や人事異動
デメリット: 役員へ情報筒抜け、危険分子の烙印(情報漏洩がホットライン直訴者に多いのは人事部の常識)、パワハラ放置で自主退職に追い込まれる
民事訴訟・調停・労働審判
メリット: 損害賠償
デメリット: 裁判費用、解雇措置、民事不介入で刑事事案化を阻止、長期係争、パワハラ上司の継続雇用
刑事告訴
メリット: 1パワハラ上司の解雇・懲戒、または2多額の和解金、1と2どちらでも被害者の雇用は維持
デメリット: 人事異動(出世コースから外れる)
◎録音は一方の当事者が取る限り合法です。※加害者に録音の同意を求める必要はありません。
◎告訴受理後の和解金は加害者の資産・収入に応じて変えてください。犯罪者の昨年の年収の半額程度×最大懲役年数が妥当です。
◎パワハラの被害についての告訴は1侮辱罪2脅迫罪3強要罪4威力業務妨害罪5傷害罪の順序で行ってください。警察・検察の協力(犯罪者の自宅・職場の強制捜査、留置所勾留)により罪の立証が楽になります。
◎刑事告訴した社員を解雇したり処遇面で著しい差別を行うことはないでしょうが、出世や管理職以上の昇進の可能性はあきらめるべきでしょう。
◎刑事告訴は民事訴訟と違って裁判による被害者への2次被害にありません。検察庁が被害者に代わって訴えをおこすので、無料で、時間と手間も告訴状をかくことと音声録音を残すだけです。
◎和解契約(公正証書・即決和解)では告訴した事実は秘匿事項となります。犯罪者が秘密保持契約を違反した場合の損害賠償金は、最低5000万円~にしましょう。
>>373
俺的には外部制約がサポートされてないことが痛い
俺的には外部制約がサポートされてないことが痛い
SELECT
(
CASE dayofweek(now())
WHEN 1 THEN '日曜日'
WHEN 2 THEN '月曜日'
WHEN 3 THEN '火曜日'
WHEN 4 THEN '水曜日'
WHEN 5 THEN '木曜日'
WHEN 6 THEN '金曜日'
WHEN 7 THEN '土曜日'
END
)
AS week
;
+------+
| week |
+------+
| 月曜日 |
+------+
1 row in set
select DATE_FORMAT(now(),'%w');
+-------------------------+
| DATE_FORMAT(now(),'%w') |
+-------------------------+
| 1 |
+-------------------------+
1 row in set
それぞれに戻り値が違う??
(
CASE dayofweek(now())
WHEN 1 THEN '日曜日'
WHEN 2 THEN '月曜日'
WHEN 3 THEN '火曜日'
WHEN 4 THEN '水曜日'
WHEN 5 THEN '木曜日'
WHEN 6 THEN '金曜日'
WHEN 7 THEN '土曜日'
END
)
AS week
;
+------+
| week |
+------+
| 月曜日 |
+------+
1 row in set
select DATE_FORMAT(now(),'%w');
+-------------------------+
| DATE_FORMAT(now(),'%w') |
+-------------------------+
| 1 |
+-------------------------+
1 row in set
それぞれに戻り値が違う??
>>378
ない
ない
素朴な疑問ですけど、1テーブルにいくらレコードがあっても
インデックスさえ適切に張っていれば、
SELECTしても瞬時にデータを取り出せるのでしょうか?
インデックスさえ適切に張っていれば、
SELECTしても瞬時にデータを取り出せるのでしょうか?
インデックスを張ったカラムのデータが全部同じで、そのデータをWHERE指定
して検索すれば全件検索あら不思議
てゆうか、このレベルの話は他でやろうよ…。MySQLであろうがなかろうが
変わらんじゃん…
して検索すれば全件検索あら不思議
てゆうか、このレベルの話は他でやろうよ…。MySQLであろうがなかろうが
変わらんじゃん…
1000万件を適切にインデックス張ってWHEREでLIMIT 1だとしても
俺の環境では参照するのに1分は余裕でかかる。
実務レベルで使うならレプリケーションとかパーティショニングとか
他の方法を考えないとな
俺の環境では参照するのに1分は余裕でかかる。
実務レベルで使うならレプリケーションとかパーティショニングとか
他の方法を考えないとな
完璧なカーディナリティのインデックスを張っているにも関わらず、
秒速5000更新でデータベースエンジンがMyISAMwwww
秒速5000更新でデータベースエンジンがMyISAMwwww
>>384
お前みたいな奴がいるから過疎る
お前みたいな奴がいるから過疎る
教えてください
5.5系同士でレプリケーションを行っていますが、マスター側の
バイナリログが新しいファイルに切り替わるとスレーブ側のバイナリログの
位置情報が勝手にマスター側の古いファイルに変わってしまいます
そのため、スレーブ側がデータの重複エラーでレプリケーションが止まってしまう状態に陥ってます
上記の現象が起こってしまう原因に心当たりのある方はいませんでしょうか・・・。
5.5系同士でレプリケーションを行っていますが、マスター側の
バイナリログが新しいファイルに切り替わるとスレーブ側のバイナリログの
位置情報が勝手にマスター側の古いファイルに変わってしまいます
そのため、スレーブ側がデータの重複エラーでレプリケーションが止まってしまう状態に陥ってます
上記の現象が起こってしまう原因に心当たりのある方はいませんでしょうか・・・。
win7 + mysql 5.5
mysqlで、select into outfile で出力した時に 文字化けが起きています
日本語で登録していたstk_nameは大丈夫なんですが、case文で分けて表示させようと
しているところなんですが。
select stock_code ,stk_name,
case shkbn
when 1 then '株式'
when 2 then 'ETF'
when 4 then 'ETN'
when 8 then 'REIT'
end as sh
into outfile "c:/no_data.csv"
fields terminated by ',' enclosed by ''
lines terminated by '\r\n'
from stock_master
で株式が 譬ェ蠑・
になってしまっているんですが、これどうしたら直るでしょうか
mysqlで、select into outfile で出力した時に 文字化けが起きています
日本語で登録していたstk_nameは大丈夫なんですが、case文で分けて表示させようと
しているところなんですが。
select stock_code ,stk_name,
case shkbn
when 1 then '株式'
when 2 then 'ETF'
when 4 then 'ETN'
when 8 then 'REIT'
end as sh
into outfile "c:/no_data.csv"
fields terminated by ',' enclosed by ''
lines terminated by '\r\n'
from stock_master
で株式が 譬ェ蠑・
になってしまっているんですが、これどうしたら直るでしょうか
MySQL 5.0.77
ODBC Driver 5.1.11
Windows 7 Pro x86 SP1
Access 2013
Access の [外部データ]-[ODBC データソース] からインポートする時、やや長めの
テーブル名を指定すると Access が死にます。
テーブル名 a23456789012345678 ⇒ OK
テーブル名 a234567890123456789 ⇒ クラッシュ
何がいけないかお分かりでしたらお教えください。
ODBC Driver 5.1.11
Windows 7 Pro x86 SP1
Access 2013
Access の [外部データ]-[ODBC データソース] からインポートする時、やや長めの
テーブル名を指定すると Access が死にます。
テーブル名 a23456789012345678 ⇒ OK
テーブル名 a234567890123456789 ⇒ クラッシュ
何がいけないかお分かりでしたらお教えください。
一応報告。
何か Driver 5.2.3 では、Access でレコードいじると
server does not support 4-byte encoded utf 8 characters
とか表示されてしまうので、5.1.10 にしました。
http://dev.mysql.com/get/Downloads/Connector-ODBC/5.1/mysql-connector-odbc-5.1.10-win32.msi/from/http://cdn.mysql.com/
何か Driver 5.2.3 では、Access でレコードいじると
server does not support 4-byte encoded utf 8 characters
とか表示されてしまうので、5.1.10 にしました。
http://dev.mysql.com/get/Downloads/Connector-ODBC/5.1/mysql-connector-odbc-5.1.10-win32.msi/from/http://cdn.mysql.com/
select 物件テーブル.*
from 物件テーブル, リレーション rel1, リレーション rel2
where 物件テーブル.物件ID=rel1.物件ID
and rel1.詳細ID=2
and 物件テーブル.物件ID=rel2.物件ID
and rel2.詳細ID=3;
てなクエリを入力パターンによって生成する
from 物件テーブル, リレーション rel1, リレーション rel2
where 物件テーブル.物件ID=rel1.物件ID
and rel1.詳細ID=2
and 物件テーブル.物件ID=rel2.物件ID
and rel2.詳細ID=3;
てなクエリを入力パターンによって生成する
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / mysql スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- MySQL 総合 Part25 (947) - [94%] - 2017/6/18 6:30
- MySQL 総合 Part24 (1010) - [94%] - 2015/2/14 4:46
- MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part22 (1001) - [94%] - 2012/7/10 16:45
- MySQL 総合 Part26 (860) - [94%] - 2023/2/2 9:30
- MySQL 総合 Part21 (1001) - [94%] - 2011/12/25 22:16
- MySQL 総合 Part20 (995) - [94%] - 2011/10/17 4:48
- MySQL 総合 Part12 (1001) - [89%] - 2008/1/30 17:34 ○
- MySQL 総合 Part18 (986) - [89%] - 2011/1/17 15:46
- MySQL 総合 Part14 (1001) - [89%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part15 (1001) - [89%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part17 (1001) - [89%] - 2010/6/10 20:47 ○
- MySQL 総合 Part19 (982) - [89%] - 2011/6/9 2:33
- MySQL vs PostgreSQL Part2 (941) - [36%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について