よろしくお願いいたします。

PostgreSQLの、

CREATE TABLE global_points (
id SERIAL PRIMARY KEY,
name VARCHAR(64),
location GEOGRAPHY(POINT,4326)
);

というSQLの、最後の
location GEOGRAPHY(POINT,4326)
というところを、MySQLで、実装しようとしているのですが、MySQLにも、地理情報に関する命令はあるようですが、どうすればよいのか見当がつかなく困っています。

どなたか、MySQLでは、こういう風に書くなどのことをご存知の方おられましたら、どんなことでも構いませんので、ご教授願います。

このQ&Aに関連する最新のQ&A

A 回答 (2件)

mysqlマニュアルではgeospatial featureと総称されるようです。

この章全部参照するのが一番かな。あんまり利用者がいないのか、日本語訳はされていない。
http://dev.mysql.com/doc/refman/5.1/ja/spatial-e …
http://dev.mysql.com/doc/refman/5.1/ja/opengis-g …

次の章あたりから、実際の例文が出てくる。カラムタイプは geometry になるらしい。
http://dev.mysql.com/doc/refman/5.1/ja/creating- …
    • good
    • 0

GEOGRAPHY型って使い勝手わるくないですか?


ざっと見てみたところGeometry型で処理するのが一般的のようですが
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

関連するカテゴリからQ&Aを探す

このQ&Aと関連する良く見られている質問

QMySQL5.1で varchar(100)のものを varchar(

MySQL5.1で varchar(100)のものを varchar(90)にする予定です。
(後ろの10バイトは無条件になくなっても構いません)

通常の手順ではalter tableを使います。
今回は、他の項目も変更(auto_incrementやキーの追加)するので
一度 mysqldumpでSQLを吐き出して、

CREATE文の以下を変更
varchar(100) → varchar(90)
auto_incrementやキーの追加

そして、mysqlでリストアします。

この方法は、アリでしょうか?

他のデータベース(PostgreSQL, SQLServer, Oracle)でも使える手法でしょうか?

皆さんのvarchar(100) → varchar(90)する方法が知りたいです。

Aベストアンサー

>varchar(100)のものを varchar(90)にする予定

一発でやるなら以下のような処理でしょうね

ALTER TABLE `テーブル` CHANGE `フィールドA` `フィールドA` VARCHAR( 90 ) NOT NULL

ただ、既存のものを処理するなら移行トラブルを避けるために、

(1)新たなフィールドをつくる
(2)update構文で古いフィールドの値を新しいフィールドにsetする
(3)データが間違いないか確認する
(4)古いフィールドを削除する

という流れにした方がよいとおもいます。

>後ろの10バイトは無条件になくなっても構いません

バイトじゃなくて文字数だと思いますが・・・

QMySQL4.1以上でのchar,varcharの定義について

環境はWindowsXP + MySQL5.0です。

MySQL5.0でテーブルを作成したところ、varchar(10)の列に入力可能なデータは『10バイト分』でななく『10文字分』でした。
(「1234567890」や「abcdefghij」に加え、「あいうえおかきくけこ」も入力可能だった)

従来(?)の『varchar(10) = 10バイト分入力可能』で定義したいのですが、なにか方法はないでしょうか?
(「1234567890」や「あいうえお」は入力可能だが、「あいうえお1」は入力不可にしたい)

http://www.mysql.gr.jp/frame/modules/bwiki/index.php?FAQ#u0cc977e
↑こちらのページによると、MySQL4.1からこのような仕様になったようですが、MySQLのバージョンは5.0のままでなにか方法はないものかと探しております。
よろしくお願いします。

Aベストアンサー

#1です。

ストアドプロシジャを使うという案も、特定の列に限って長さをチェックするというものでして、スマートではありません。

ある表のある列の定義情報(長さ)を得る方法、その退避方法といったところが問題になりそうですね。

create table t1
(c1 varchar(10) check(length(c1)<=10);

日本語では検査制約と呼ぶのかな?checkが使えないかと思ったのですが、MySQLでは「構文チェックはするが、実際に制約は働かない」という中途半端なサポート状況のようです。

QTEXTでのPRIMARY KEYの使い方

customer テーブルを作って、その中にname, email, passwordをそれぞれtext型が入ってます。その後にalter table customer add customer primary key(email);で、emailにprimary keyをつけようとしてるのですが、ERROR1170 Bolb/Text column 'email' used in key specification without a key lengthと言ってます。textの大きさを指定とかするべきなのでしょうか??本当はcreateの最初の段階で、primary keyを入れたかったのですが、その時も同じエラーが出たため、tableを作ってから追加しようと試みてます。他の型で試してみたら、primary keyは難なく追加できました。text型だと何かやり方が違うのでしょうか。ちなみに全てnot nullに設定してあります。回答お願いします。

Aベストアンサー

http://dev.mysql.com/doc/refman/4.1/ja/create-table.html

によると、text型とblob型は255バイト以内で
長さを指定する必要があるようです。
こんな感じになるのでしょうか

alter table `customer` add primary key(`email`(100));

Qcreate時にFOREIGN KEYでエラー

以下のSQL文を実行すると

CREATE TABLE if not exists table_A (
idint(11) not null auto_increment,
company_idint(11) not null,
created_atdatetime NOT NULL,
updated_attimestamp NOT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;


CREATE TABLE if not exists table_B (
idint(11) not null auto_increment,
from_idint(11) not null,
company_idint(11) not null,
created_atdatetime NOT NULL,
updated_attimestamp NOT NULL,
PRIMARY KEY (id)
FOREIGN KEY (from_id)
REFERENCES table_A(id)
ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

上記を実行すると以下のエラーがでます。

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FOREIGN KEY (from_id)
REFERENCES table_A(id)
ON DELETE CASCADE
) ENGINE=Inn' at line 8

解決方法をご存知の方はご教示頂けますと幸いです。
宜しくお願いいたします。

以下のSQL文を実行すると

CREATE TABLE if not exists table_A (
idint(11) not null auto_increment,
company_idint(11) not null,
created_atdatetime NOT NULL,
updated_attimestamp NOT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;


CREATE TABLE if not exists table_B (
idint(11) not null auto_increment,
from_idint(11) not null,
company_idint(11) not null,
created_atdatetime NOT NULL,
updated_attimestamp NOT NULL,
PRIMARY KEY (id)
FOREIGN KEY...続きを読む

Aベストアンサー

PRIMARY KEY (id)
FOREIGN KEY (from_id)

の間にカンマが必要では?

QMySQLのvarchar型とtext型について

以下のURLのページを読んだのですがよく理解できません。。。
http://dev.mysql.com/doc/refman/4.1/ja/storage-requirements.html
http://dev.mysql.com/doc/refman/4.1/ja/blob.html

例えば'abc'という文字列を格納するとした場合、記憶容量は
varchar型では3+1バイト、text型では3+2バイトとなるようですが、
1バイト(varchar)と2バイト(text)の違い以外で、
text型の方がDBに負担がかかるとか不利になるようなことはありますか?

text型では格納する文字列の長さに関係無く、65535バイトを常に確保しているとか…
text型の方が動作が遅いとか…

現状、255バイト以下を想定しているのでvarchar(255)にするつもりですが、
将来的に256バイト以上となることもありえるので
最初からtext型にしていた方がいいのでしょうか?
また、将来text型に変更した際にパフォーマンスが落ちる等といったことがありえるのでしょうか?

宜しくお願い致します。

以下のURLのページを読んだのですがよく理解できません。。。
http://dev.mysql.com/doc/refman/4.1/ja/storage-requirements.html
http://dev.mysql.com/doc/refman/4.1/ja/blob.html

例えば'abc'という文字列を格納するとした場合、記憶容量は
varchar型では3+1バイト、text型では3+2バイトとなるようですが、
1バイト(varchar)と2バイト(text)の違い以外で、
text型の方がDBに負担がかかるとか不利になるようなことはありますか?

text型では格納する文字列の長さに関係無く、65535バイトを常に確保...続きを読む

Aベストアンサー

#1です。

そういえば部分インデックスがありましたね。
使ったことないので忘れてました。失礼しました。
私見でもうしわけないですが部分インデックスは若干
運用方法も気をつける必要がありそうなので、
微妙な気がします。

とりあえず#1の私の回答は参考にならなかったような
ので、あとは誰か別の人にきいてください


人気Q&Aランキング

おすすめ情報