i have row "user" in table group "user" have array value = "['1', '55' , '199']" have get all group where in array "55"?

where user = 55

user = "['1', '55' , '199']"

или "['55', '234' , '4577']"

нужно найти все где есть в масиве 55

where user like '%55%'

а если будет 555

или 1055

найдет все, где есть 55

спс

Не добавить ограничения внешнего ключа, выдаёт ошибку #1215 - Cannot add foreign key constraint. Типы полей полностью одинаковые, перепроверил 100 раз.

Внешних же ключей может быть несколько? Просто в таблицах, где хочу ещё по одному добавить, уже есть один внешний по каждому.

причин для этой ошибки может быть много. причину нужно смотреть так:

mysql> pager grep -A 5 FOREIGN

mysql> show engine innodb status;

данные правильные?

встал вопрос. Как хранить древовидную информацию в базах данных?(простейщий xml, json или любой другой формат) Например данные типа: - Persons: - - id: 1 - - name: "John: - - Age: 26 - - Car: 1 - Cars: - - id: 1 - - type: "audi a4" Собственно должно быть не две таблицы Persons и Cars, а что-то совсем другое, так как данные могут быть другие, и структура другая. Первое что мне пришло в голову это следующие таблицы: Таблица types(id, type_name) Таблица values(id, type_id, value_id) несколько таблиц для типов: Таблица int_values(value_id, value) Таблица string_values(value_id, value) Таблица array_values(value_id, value varchar) и из таблицы array_values из строки извлекаются все внутренние ветки дерева. Но мне что-то подсказывает, что такой способ будет не оптимальным, когда начнется выполнение select/update из приложения. Возможно, нужно будет написать процедур в бд, но пока вопрос не в этом - есть ли способ лучше организовать структуру данных в этом случае?

nosql почитай

встал вопрос. Как хранить древовидную информацию в базах данных?(простейщий xml, json или любой другой формат) Например данные типа: - Persons: - - id: 1 - - name: "John: - - Age: 26 - - Car: 1 - Cars: - - id: 1 - - type: "audi a4" Собственно должно быть не две таблицы Persons и Cars, а что-то совсем другое, так как данные могут быть другие, и структура другая. Первое что мне пришло в голову это следующие таблицы: Таблица types(id, type_name) Таблица values(id, type_id, value_id) несколько таблиц для типов: Таблица int_values(value_id, value) Таблица string_values(value_id, value) Таблица array_values(value_id, value varchar) и из таблицы array_values из строки извлекаются все внутренние ветки дерева. Но мне что-то подсказывает, что такой способ будет не оптимальным, когда начнется выполнение select/update из приложения. Возможно, нужно будет написать процедур в бд, но пока вопрос не в этом - есть ли способ лучше организовать структуру данных в этом случае?

Можно работать отдельно с типами в коде, а в базе хранить текстовый.

как варик, если так уже хочется в mysql - можно почитать интересную статью uber как они schemaless поверх мускуля готовят

А какие способы вы уже рассматривали и какие отвергли и почему? json, nested set, materialized path, etc ?

А какие способы вы уже рассматривали и какие отвергли и почему? json, nested set, materialized path, etc ?

Я пока экспериментирую просто. В дальнейшем, если суметь сохранить данные разных типов в неизменной по структуре бд, есть идея хранить также условия, предикаты и атрибуты для значений values в этой же структуре.

Вообще все начинается с того, что существует система мерчендайзинга (сервер+мобильная часть). Система огромна. Она поставляется для нескольких компаний. У каждой компании есть свои требования, и мне, как программисту, пришлось клонировать систему для каждой компании и в каждом клоне дописывать условный код и схему бд. Собственно если бы часть условной логики можно было бы перенести в бд... и для того чтобы условия можно было применять к любым типам данных, данные нужно декомпозировать в простейшие единицы. Не знаю, может это вовсе бред?))

nosql почитай

Оно походу

А может просто нужно БД нормально спроектировать, со всеми таблицами, внешними ключами и констрейнтами? )

В общем твой вопрос слишком абстрактный, этим и занимаются архитекторы впринципе. На фуллтайме сидят и рассматривают разные кейсы, беседуют с БА, смотрят, замеры делают.

В общем твой вопрос слишком абстрактный, этим и занимаются архитекторы впринципе. На фуллтайме сидят и рассматривают разные кейсы, беседуют с БА, смотрят, замеры делают.

Может Вы знаете случайно где поискать дополнительную информацию по подобной архитектуре? (даже если nosql)

Выкладки, статьи, книги... что угодно)

В общем твой вопрос слишком абстрактный, этим и занимаются архитекторы впринципе. На фуллтайме сидят и рассматривают разные кейсы, беседуют с БА, смотрят, замеры делают.

поддержу, инструмент выбирается под задачу, и что тебе выбрать будет зависить от конкретно твоего юзкейса

у тебя же есть ряд требований к системе, начни с анализа требований

Выкладки, статьи, книги... что угодно)

Затрудняюсь, единственное, насколько я смог понять из объясненей, это не обычный кейс хранения деревьев (типа nested set/adj list) а все же больше случай именно данных с динамической схемой. Значит скорее всего JSON

Хорошо, буду копаться, спасибо.

Короче, пересоздал поля по собственноручному запросу, всё пошло, как нужно без ошибок.

тут нужно было внимательно посмотреть на: 1. типы данных в создаваемой и referenced таблицах. 2. индексах в referenced таблице и 3. default collation

раз всё решилось после пересоздания поля, вангую, что поменялась default collation

раз всё решилось после пересоздания поля, вангую, что поменялась default collation

Да, потому что с первыми двумя всё в порядке

данные были, до пересоздания?

раз всё решилось после пересоздания поля, вангую, что поменялась default collation

хм, про коллейшены не знал, интересно

Короче, пересоздал поля по собственноручному запросу, всё пошло, как нужно без ошибок.

а какая версия мускуля?

а какая версия мускуля?

5.7.20

ДОбрый день! Реально ли сделать такой финт на уровне MySQL. При удалении записи в таблице A удалять все записи в таблице Б, где Б.object_id = A.id and Б.object_type = "А" ?

ДОбрый день! Реально ли сделать такой финт на уровне MySQL. При удалении записи в таблице A удалять все записи в таблице Б, где Б.object_id = A.id and Б.object_type = "А" ?

да, через FK

да, через FK

Хм.. как через FK?

Пока пришел к тригерам...

вот для примера CREATE TABLE `reports` ( `id` int(11) NOT NULL AUTO_INCREMENT, `reportid` int(11) DEFAULT NULL, `clientcode` int(11) NOT NULL, `client_id` varchar(50) DEFAULT NULL, `datedeliveri` datetime DEFAULT NULL, `status` varchar(50) DEFAULT NULL, `plateg` varchar(50) DEFAULT NULL, `priceuslug` varchar(50) DEFAULT NULL, `ds` varchar(3) DEFAULT NULL, PRIMARY KEY (`id`), KEY `reportid` (`reportid`), CONSTRAINT `reports_ibfk_1` FOREIGN KEY (`reportid`) REFERENCES `report` (`id`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=371 DEFAULT CHARSET=utf8

Б.object_id = A.id and Б.object_type = "А" такой финт FK не сделаешь

CREATE TABLE `report` ( `id` int(11) NOT NULL AUTO_INCREMENT, `companycode` int(11) NOT NULL, `ldtime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `companycode` (`companycode`) ) ENGINE=InnoDB AUTO_INCREMENT=28 DEFAULT CHARSET=utf8 вот если из этой таблицы удалить запись, то в таблице выше удалятся все записи с данным id

Это не то

У меня два столбца, а не один с ID

и?

ну и как сделать FK?? При удалении записи в таблице A удалять все записи в таблице Б, где Б.object_id = A.id and Б.object_type = "А" ?

хочешь удалять только из столбца?

хочу удалять все строки в таблице Б, где Б.object_id = A.id and Б.object_type = "A"

можешь сделать составной FK, правда для этого необходимо будет, чтобы этот дополнительный атрибут был в обеих таблицах ну или через триггеры, только не забудь, что на каскадных удалениях на дочерних таблицах они не срабатывают

ну и крайний вариант, напиши хранимку

можешь сделать составной FK, правда для этого необходимо будет, чтобы этот дополнительный атрибут был в обеих таблицах ну или через триггеры, только не забудь, что на каскадных удалениях на дочерних таблицах они не срабатывают

только что открыл для себя как раз фишку с каскадным удалением :)

Сталкиваюсь с ошибкой 1452, если пишу просто запрос. Если до и после него поставить SET FOREIGN_KEY_CHECKS, то всё ок, просто первый и третий никак по времени не влияет, если верить отчёту после выполнения запросов. SET FOREIGN_KEY_CHECKS=0; INSERT INTO kuku(id, a, b, c, d) VALUES (1,2,3,4,5); SET FOREIGN_KEY_CHECKS=1; Как избавиться от этого? 1452 — это про внешние ключи. Да, они у меня есть. Всегда такой костыль нужен?

Может просто в родительскую таблицу сначала добавить значение а не страдать такой херней?

Может просто в родительскую таблицу сначала добавить значение а не страдать такой херней?

Как раз родительская и есть. И есть уже значение.

Может просто в родительскую таблицу сначала добавить значение а не страдать такой херней?

он не отвечает на вопрос, у него 2 раза спросил про данные

забей

Ок

данные были, до пересоздания?

данных не было

он не отвечает на вопрос, у него 2 раза спросил про данные

Я не увидел, прошу прощения

какой запрос делаешь

какие данные в бд

на момент запроса, пусто?

какие типы колонок, обе колонки правильно написаны?

бд на которую ссылаеться существует?

у тебя явно какая-то синтаксическая ошибка

проверь все вышесказанное

данные которые вставляються по ключу, должны быть и в родители, это так?

поле на которое ссылаешься primary key?

скинь запрос на создание таблиц

с ключами

на какой ключ ругается?

у тебя поле telegram_id ссылаеться на 5 таблиц с таким полем

это законно?

во всех 5 таблицах, есть значение которое ты вставляешь?

почитай про foreign ключи

тебе нужно ключи с этой таблицы распихать на 5 таблиц

по 1

CONSTRAINT accounts_ibfk_1 FOREIGN KEY (telegram_id) REFERENCES accounts (telegram_id) ON DELETE CASCADE ON UPDATE CASCADE, - этот в request и т.д.

и если ты задал для таблицы, то для полей не надо

CHARSET=latin1 COLLATE=latin1_bin