似たようなデータベース作ったからって、泥棒よばわりするのやめてもらえません？
連載目次 久しぶりにソフトウェアの著作権の判例を解説する。 今回の判決は、以前「データベースをパクられたので、著作権侵害で9億円請求します！」で一度取り上げ、その考え方も説明したが、著作権の考え方を整理し直す機会として、あえて再度解説することにした。 著作権法は第二条において、コンピュータのプログラムやデータベース、通信などに関する作成物も著作物として認められると示している。しかし、こうした成果物の全てに著作権が認められるわけではない。仮に誰かが何も参考にせず、一から以下のようなプログラムを書いたとしても、これを「著作物」だと主張するのは難しい。 このプログラムを書くためには、プログラミング言語に関する最低限の知識があれば足りる。そこにプログラマーの創意や工夫、まして思想、信条などというものはない。こうしたプログラムは著作権保護の対象とはならないだろう。 だが、創意や工夫が作成したプログラ
DBMSをGoで実装してみた - Sansan Tech Blog
こんにちは。プロダクト開発部の荒川 id:ad-sho-loko です。突然ですが、皆さんはこんな疑問を持ったことはありませんか？ データベースの内部実装はどうなっているのか？ トランザクションとはどのようなアルゴリズムで実現されているのか？ NoSQLが遅いのはなぜか？ 古典的なデータベースとは内部的にどのように違うの？ データベースを何かしらの形で利用しているのにも関わらず、意外と内部の仕組みを理解していない場合が多いかと思います。僕もそうです。*1 しかし、エンジニアたるもの、その仕組みを知ることは非常に重要です。僕もデータベースについて勉強しようといくつかの本やサイトを調べていたのですが、なかでもCMU（カーネギーメロン大学）のDatabase System Groupがアップロードしている講義が最も勉強になりました。 www.youtube.com そして本ブログでは、上記の講義
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
Firebase Realtime DBを実践投入するにあたって考えたこと - Qiita
Firebase Realtime DBを実践に投入する Databaseと聞くと、これから利用しようとするFirebaseがmBaaSであることを忘れてついREST(Client Server Model)で考えてしまいがちですが、大前提はMobile Platformなので、一度REST、RDBの考え方は捨ててみてください。 RDBの考え方を引き継いだままでは、Firebase Realtime DBの最善の設計はできないと考えています。 そして、RDBの考え方を引き継いだままFirebase Realtime DBを理解しようとすることが、導入の一つの障壁となっていると思っています。 ぜひ頭をリフレッシュしてFirebase Realtime DBの見方を変えてみてください。 この記事では、Firebase Realtime DBの導入するにあたっての考え方やテクニックを紹介します。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
イミュータブルデータモデル(入門編)