タグ付けされた質問 「sql」

アルゴリズムのドキュメントには何を含める必要があるのでしょうか。従うべき適切なガイドラインが見つかりません。含めることを心に留めています アルゴリズムの要約 アルゴリズムの説明 フローチャート 疑似コード 入力データセットのサンプル（複数） 出力データ 単体テスト 実験 クライアントは次のような文書を要求します。自社の数値に自信を持たせるとともに、プロセスを見込み顧客に説明して、計算をチェックおよび検証するための手順を踏んでいることを顧客に説明します。 そのようなドキュメントはどのように見えますか？（PDFの例） このドキュメントに何を追加しますか？ 私が列挙したものはそれで良いですか、またはこれはどういうわけか異なって文書化されるべきですか？ このようなドキュメントサンプルをGoogleでどのように検索しますか？

10 java  php  algorithms  documentation  sql 

ローカルアプリケーション（WPFおよびC＃で開発）であるため、一度に1人のユーザーしか使用しない小さなプロジェクトに取り組んでいます。データを保存するには、XMLファイルを使用することを考えていましたが、これが最善の方法かどうか疑問に思っています。 データの目的： シェドル フォルダ内のファイルのライブラリ（アーティスト名、タイトル、HDD上の場所） おそらく、シェドゥルデータに基づく統計 ... ライブラリに関する情報は私が想像するXMLで十分でしょうが、残りのすべてについては私にはよくわかりません。また、LINQ to SQLは、LINQ to XMLよりも開発速度の点ではるかに収益性が高いようです。これは正しいですか、それとも間違っていますか？これをSOとここのどちらに投稿すればよいかわかりませんでしたが、こちらのほうが適切に思えました。 前もって感謝します

10 sql  wpf  xml 

SQLステートメント、関数、およびストアドプロシージャの正当性をテスト/検証するために、証明の形式でリレーショナル代数および/またはリレーショナル計算を使用することは可能ですか、それとも可能ですか？ 少なくともそれは可能であるように思えますが、証拠とコードの間の1：1マッピングを不正確にする欠落している詳細があるかどうかはわかりません。 このような方法を試した人はいますか？うまくいきましたか？どのような体験をしましたか？

9 testing  sql  math  relational-database 

ある会社が現在利用しているシステムと、それをどうするかについて話し合った。 同社はさまざまなカートンディスプレイを製造しています。このシステムは、クライアント、注文、価格を追跡するために開発されました。システムが作成されてから多くのことが起こりましたが、システムは、マネージャーが説明したように、「ロックされている」と「問題がある」ので、私は「動的ではない」と「不安定」と解釈しています。 システムに関するいくつかの情報 2000年頃に開発されました かなり小規模なシステム、2〜5人のユーザー、6つのフォーム、平均量のデータを含む最大8つのテーブル 初期のVisual Basicに基づいて構築された、ドラッグアンドドロップデザインで作成されたフォーム。インターフェイスは基本的にメニューといくつかのフォームを備えた単なるウィンドウです MSSQLデータベース（SQL2005サーバー）を使用してデータとクエリ用のODBCドライバーを格納し、データがこのシステムの前にExcelから移行され、Excelの前に手動で処理され、計算され、記述された ユーザーはMicrosoft XP環境（およびそれ以上）で作業します 彼らの主な問題は、価格を調整および計算できない、新しいカートンタイプなどを正しく追加できない、サーバー上のデータにアクセスできない（または、方法がわからない）ため、もう正しくできないことです。 私は3つの可能な解決策を提案しました 現在のシステムにパッチを適用しようとする 新しい新しいインターフェースを作成します（できれば、同様の環境、VB.netまたはVBベース） 非常に小さなシステムであることを考慮して、Excelソリューションに戻します さらに多くのオプションがあるかもしれませんが、これらは私が考えることができるものです。 私の質問は 私は何を勧めるべきですか、そしてなぜですか？ これらの代替案の長所と短所は何ですか？ 他の（おそらくより良い）代替案はありますか？

9 sql  refactoring  excel  visual-basic 

C＃でMS SQL Serverからデータを照会する最良の方法は何ですか？ コードにSQLクエリを含めることはお勧めしません。 ストアドプロシージャを作成し、パラメーターを使用してC＃から呼び出すのに最適な方法は何ですか？ using (var conn = new SqlConnection(connStr)) using (var command = new SqlCommand("StoredProc", conn) { CommandType = CommandType.StoredProcedure }) { conn.Open(); command.ExecuteNonQuery(); conn.Close(); }

9 c#  sql  sql-server 

過去2か月ほどの間、データベース内のリリース管理を処理するためのソリューションまたはプラクティスを探していました。これを処理するための最良のプロセスとして人々が見ているものを探しています。 データベースには3つの環境があります。 開発 ユーザー受け入れテスト（UAT） 製造 問題は、開発データベース内のいくつかのものに変更を加えて展開するときが来ていることです。一部の機能はUATにリリースする準備ができていない可能性があります。 最近、すべてのエンティティを（通常のコミットで）格納するためにRed Gate SQLソースコントロールを使用し始めました。 私はチェンジセットに基づいて行くことを考えていました（つまり、チェンジセットXからすべてがUATにプッシュされていると言います）、つまり、混乱を招く可能性のあるデプロイを行う直前に、人々がコードをソース管理にチェックインしているだけです（特に人々は忘れっぽいからです）。変更セットのアプローチに伴うもう1つの問題は、修正が必要なストアドプロシージャにバグがある場合、変更セット番号は最終的にリビジョンの最大変更セットの範囲外になるため、必要に応じて最大のチェンジセットからデータベースを再作成します。バグを再度プッシュします。 プロセスに関する提案はありますか？ ありがとう

9 database  sql  sql-server  tsql 

私はCSの学生として、長年にわたってまともな数のプログラミング言語を学びました。そのほとんどは、「null可能」または「オプション」タイプの概念を持っています。ここでは、nullポインターや参照、JavaScriptのような弱く型付けされた言語については触れていませんnull。私が話していることの例には、boost::optional（C ++）、java.util.Optional（Java 8.0）、prelude.Maybe（Haskell）、およびすべての「？」種類（例えばint?、float?、C＃やKotlin）。これらは、厳密な静的型システム内で、以前はnullにすることができなかった型にnullの可能性を追加する構成体です。 SQLにも同様の概念があります。たとえば、INTEGERnull可能またはnull不可にできるような型ですが、ひねりがあります。SQLでは、INTEGERデフォルトでnull可能であり、null INTEGER NOT NULL不可になるように明示的に記述する必要があります。 NULLをデフォルトの動作にすることを許可することは非常に直観に反し、潜在的に危険であると私は思います。明らかに、SQLはこの時点で非常に長い間存在しており、（ほとんどの）SQL開発者はNULLの落とし穴について健全な認識を築いています。しかし、私は仕方がないのですが、初期の頃、NULLが予期せず問題のある場所に忍び込んでいたことを想像してみてください。 SQLは私が提供したすべての例よりも古いため、これは単に歴史的な進化の問題である可能性があります。それでも、私は尋ねなければなりません、言語がこのように設計され、型がデフォルトでnull可能であるという正当な理由はありますか？ もしそうなら、それは単なる歴史的な理由でしょうか、それとも今日のデータベース設計にロジックは耐えますか？ 編集：なぜNULLがSQLの一部であるのか、またはNULL可能列がなぜ有用なのかは尋ねていません。列がデフォルトで null可能である理由を尋ねています。たとえば、次のように書くのはなぜですか。 column1 FLOAT, column2 FLOAT NOT NULL のではなく： column1 FLOAT NULLABLE, column2 FLOAT

8 sql  language-design  null 

データベースへのアクセスにjavaまたはpythonを使用しているとします。それでは、時間の浪費と見なされ、SQL内で使用されているデータ構造とオブジェクトの種類を学習する必要はありませんか？ ソフトウェア業界についてお答えください。どのような場合にそのようなことを知っておくとよいかを教えてください。 私はそのようなことを学ぶ必要はないと言っている誰かとの議論があります。

8 database  sql 

私はeコマース製品を開発しており、すべての機能を実装できたため、ユーザーが製品の追加属性を作成できるようになりました。現在、私には2つのオプションがあります。 EAV EAVは主に眉をひそめていますが、Magentoで動作するようです。しかし、すべての頭痛を調査した後、それを使用するのには少し気が進まなくなります MySql 5.7でJSON列を使用する これはかなり新しいものであり、他のどこにも実装されていないので、JSON属性を照会した結果として全テーブルスキャンを実行するのは大変です。しかし、このMySql 5.7 JSONを読んだ後、彼らはJSONの使用を推奨しているようです。そして、この実用的なMySqlスキーマアドバイスのようなものを実装するよりも、それほど面倒ではありません。 私の質問は、NoSQLは私にとってオプションではないので、属性を格納するJSON列の方法を使用することに偏っていますが、EAVテーブルを使用するよりも深刻な欠点があります。

8 performance  sql  mysql 

データベースへのインターフェースを提供するREST APIの機械で読み取り可能な記述（WADL、Swagger、RAMLなど）があるとします。 私のユーザーは、基になるデータベースに関するクエリをSQLまたは同様のクエリ言語の形式で送信します。ただし、REST APIを介してのみ、データベースに直接アクセスすることはできません。 そのようなSQLクエリを特定のREST APIへの一連のリクエストに変換するシステムを（できれば記述から半自動で）構築するには、どのアプローチを選択しますか？ そのような問題をどのように表現しますか？役立つアルゴリズム、理論的フレームワーク、またはツールはありますか？ REST APIは以下をサポートします。 読み取り専用操作、つまりSELECTSQLクエリのみ XPartialプロジェクション（例/persons?fields=firstname,lastname） RSQL制約（別の例を/persons?query=firstname==John;department.code==42参照）。 テーブル間の一部の参照（外部キー）はREST APIでは属性として表されますが（Person.department上記の制約の例など）、一部の参照はサブリソース（例：）として表されます/persons/{userName}/projects。つまり、一部のクエリでは、RESTリクエストに関して回答される「計画」を考案する必要があります。 例：「チャックノリスのアクティブなプロジェクトの名前」のクエリは、次のように変換されます。 /persons?query=firstname==Chuck;lastname==Norris userName結果から得る /projects/{userName}?fields=name&query=state==ACTIVE

8 java  sql  rest  planning  translate 

Linuxで小さなデータロギングアプリケーションをセットアップしようとしています。データはシリアルポート経由で届き、そこからロギングとグラフィック表示に送られます。 ログ機能は、再起動後のグラフ機能の初期化のためにあります。 データは毎秒到着し、5桁の10進数の精度で構成され、2年間記録する必要があります。私の現在の空き容量は約15GBです。 これまでのプロジェクトの言語はbashとpythonです。 私の目的は、シンプルでありながら堅牢な（おそらくフラッシュドライブへのライブバックアップ？ SQLiteはこれに適していますか？私のホームディレクトリにあるテキストファイルはこれに適していますか？

8 python  sql  logging 

私はプロのソフトウェア開発者にとって非常に新しいと言って、この質問の前置きをします。 私は社内の他のグループからデータを受け取り、このデータをビジネスエグゼクティブが使用できるレポートに変換するチームで作業しています。 データの転送と解析の過程で、データの多くの処理を行ういくつかのSQLステートメントがあります。ほぼすべてのSELECT用途はTRIM、SUBSTR、CASTなど広範囲に適切なサイズや形式にフィールドを軽減します。さらに、CASE内SELECTのステートメントを使用することで説明される特別なケースがたくさんあります。 私たちが使用するTeradataサーバーソフトウェアは、非常にわかりにくいエラーメッセージを出力します。その結果、どのデータがどのSQLステートメントを壊しているかについて、多くの推測を行います。 私の質問は、これらのやや複雑なSQLステートメントを、処理と特殊なケースの処理を省略した、より複雑でない形式に減らし、代わりにこれを外部のスクリプトまたはプログラムで実行することは良い考えでしょうか？これは意味がありますか？

8 sql  complexity 

次の質問では、フィールドとテーブルの名前がIDを保護するために変更されています。 2つのデータベース列がある場合： MONKEY_DATE DATETIME NULL (with data e.g. 2012-05-14 00:00:00.000) MONKEY_TIME DATETIME NULL (with data e.g. 1753-01-01 16:30:53.025) 時間フィールドの日付コンポーネントは、ほとんどが1753年1月1日に設定されています...しかし、一部のデータは1899年1月1日で、一部は1900年1月1日です。 これらの列をクエリおよびレポートするコードを維持すると、私（および私たちのチーム）は2つの列をマージすることで簡単に解決できる頭痛の種を引き起こします。しかし、経験（およびTerry Goodkind）は、決して簡単なことはないことを教えてくれました。これが頭痛の原因であるいくつかの例を以下に示します。 私のアプローチ 次のアプローチには、2つの列をマージするという望ましい効果があると思います。 SQLを使用してデータを更新し、日付フィールドの値と時間フィールドの値の両方を同じ値に設定します。これは、日付フィールドの日付コンポーネントと時間フィールドの時間コンポーネントの混合です。 MONKEY_DATEフィールドのみを使用して新しいコードを記述します 最終的にMONKEY_TIMEフィールドと日付/時刻コンポーネントSQLを段階的に廃止します（例を参照） MONKEY_TIMEをドロップ これは、すぐに行ってシステム全体に遡及的な変更を加える必要がないことを意味します。既存のコードはすべて引き続き機能します...そして、正しい方法で作業を開始できます。 ＃1のSQLは（Oracle）の場合があります。 UPDATE MONKEY SET MONKEY_DATE = TO_DATE(TO_CHAR(MONKEY_DATE, 'MM/DD/YYYY ') || TO_CHAR(MONKEY_TIME, 'HH24:MI:SS'), 'MM/DD/YYYY HH24:MI:SS') MONKEY_TIME = TO_DATE(TO_CHAR(MONKEY_DATE, 'MM/DD/YYYY ') || TO_CHAR(MONKEY_TIME, 'HH24:MI:SS'), …

8 design-patterns  sql  database-design  decisions