Каков наиболее эффективный способ хранения массива целых чисел в столбце MySQL?
MySql не может знать, как хранить объект GEO, или каков его размер. Вы не должны хранить объект так, как вы пытаетесь.
Документация PreparedStatement # setObject () гласит:
Спецификация JDBC указывает стандартное сопоставление типов объектов Java с типами SQL. Данный аргумент будет преобразован в соответствующий тип SQL перед отправкой в базу данных. [...] Этот метод генерирует исключение, если существует двусмысленность, например, если объект имеет класс, реализующий более одного из интерфейсов, названных выше.
blockquote>
5 ответов
Если вы собираетесь искать как по лесу, так и по растению, похоже, вам будет полезно использовать полноценные отношения "многие ко многим". Удалите столбец plants и создайте совершенно новую таблицу areas_plants (или как вы хотите ее назвать), чтобы связать эти две таблицы.
Если область 1 имеет растения 1 и 2, а область 2 имеет растения 2 и 3, ваша таблица areas_plants будет выглядеть следующим образом:
area_id | plant_id | sort_idx
-----------------------------
1 | 1 | 0
1 | 2 | 1
2 | 2 | 0
2 | 3 | 1
Затем вы можете просмотреть отношения с любой стороны и использовать простые JOIN, чтобы получить соответствующие данные из любой таблицы. Нет необходимости копаться в условиях LIKE, чтобы выяснить, есть ли это в списке, бла-бла-бла. Я был там с унаследованной базой данных. Никакого удовольствия. Используйте SQL по максимуму.
Как насчет этого:
таблица: растения
plant_ID | name
1 | tree
2 | shrubbery
20 | notashrubbery
таблица: области
area_ID | name
1 | forest
таблица: area_plant_map
area_ID | plant_ID | sequence
1 | 1 | 0
1 | 2 | 1
1 | 20 | 2
Это стандартный нормализованный способ сделать это (с таблицей сопоставления).
Чтобы найти все области с кустарником (растение 2), сделайте следующее:
SELECT *
FROM areas
INNER JOIN area_plant_map ON areas.area_ID = area_plant_map.area_ID
WHERE plant_ID = 2
Вы знаете, что это нарушает нормальную форму?
Как правило, есть таблица areaplants: area_ID, plant_ID с уникальным ограничением для двух и внешними ключами для двух других таблиц. Эта таблица «ссылок» - это то, что дает вам отношения «многие-многие» или «многие-к-одному».
Запросы по этому поводу обычно очень эффективны, они используют индексы и не требуют синтаксического анализа строк.
Атрибуты отношения должны быть атомарными, а не состоять из нескольких значений, таких как списки. Их слишком сложно искать. Вам нужно новое отношение, которое сопоставляет заводы с area_ID, а комбинация area_ID / plant является первичным ключом.
Используйте отношение «многие ко многим»:
CREATE TABLE plant (
plant_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(255)
) ENGINE=INNODB;
CREATE TABLE area (
area_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(255)
) ENGINE=INNODB;
CREATE TABLE plant_area_xref (
plant_id INT NOT NULL,
area_id INT NOT NULL,
sort_idx INT NOT NULL,
FOREIGN KEY (plant_id) REFERENCES plant(plant_id) ON DELETE CASCADE,
FOREIGN KEY (area_id) REFERENCES area(area_id) ON DELETE CASCADE,
PRIMARY KEY (plant_id, area_id, sort_idx)
) ENGINE=INNODB;
РЕДАКТИРОВАТЬ:
Просто чтобы ответить на ваш бонусный вопрос:
Bonus Question Is it time to step away from MySQL? Is there a better DB to manage this?
Это не имеет ничего общего с MySQL. Это просто проблема с плохим дизайном базы данных. Для подобных случаев вы должны использовать таблицы пересечений и отношения «многие ко многим» во всех СУБД (MySQL, Oracle, MSSQL, PostgreSQL и т. Д.).