Форум пользователей MySQL

oowriter 3.2 падает на этом файле

Попробуйте представить в виде нескольких текстовых файлов. Обнаружите, что
это дико удобно

Хм. А Вы не пробовали пользоваться mysqldump для создания текстовых файлов?
Не нужно было бы тратить столько усилий Вам, и (с моей точки зрения — главное)
не нужно было бы тратить столько усилий мне, чтобы загрузить эти данные в тесто-
вую базу

Теперь что касается самой проблемы — она дико нереалистично выглядит. Скорее
всего, у Вас очень неудачно хранятся данные. При нормальной организации такие
вопросы не возникают. Плоха проблема тем, что она недетерминистична (т.е. при
одних и тех же данных в таблицах Вы не можете внятно сформулировать, какие
данные Вы ожидаете получить в выборке). Поясню на примере.

Исходные данные:
WorkId  CompId  DispId  PrintId ScanId  UserId
1       1       1       пусто   1       1
1       1       1       пусто   1       2
1       1       1       пусто   1       3
1       1       2       пусто   1       1
1       1       2       пусто   1       2
1       1       2       пусто   1       3

Желаемое:
1       1       1       пусто   1       1
1       пусто   2       пусто   пусто   2
1       пусто   пусто   пусто   пусто   3

Альтернативное желаемое:
1       1       2       пусто   1       1
1       пусто   1       пусто   пусто   2
1       пусто   пусто   пусто   пусто   3

Я добавил раздел «альтернативное желаемое», которое точно так же следует из
тех же самых данных и полностью удовлетворяет Вашим требованиям желаемого.
Более того, этих альтернативных желаемых много. Именно поэтому Вам не удается
сформулировать запрос — его нельзя сформулировать.

Соответственно, решение — подумать, какую действительно задачку Вы решаете.
И решать реальную задачку, а не эту. Например, я допускаю, что Вас устроит
решение с GROUP_CONCAT по всем полям, кроме первого, и группировкой по первому
полю.

dimkainc - Вы не правильно нарисовали связи. Все связи привязаны к рабочему месту(к одной точке объединения).
А должно быть в виде дерева.

Tsvetkov написал:

dimkainc - Вы не правильно нарисовали связи. Все связи привязаны к рабочему месту(к одной точке объединения).
А должно быть в виде дерева.

А что делать, если так оно и есть. Любое оборудование может быть установлено на конкретное рабочее место, и от замены оборудования, работоспособность за рабочим местом не изменится. То же самое и про пользователей - они работают в разные смены, но за одним рабочим местом. Нет ни чего закреплённого друг за другом, а только за этим самым рабочим местом. Соответсвенно резерв хранится на складе и, по мере поломок, со склада берут замену.

Ну так и группируйте тогда?

Tsvetkov написал:

Вы подключаете монитор к компьютеру , а не к рабочему месту. И когда Вы производите
соединение через WorkState  таблици Computers и Display,  то происходит перемножение.
И вместо 2-х записей получаете 4 записи для 1 рабочего места.

Т.е. неправильно спроектировали базу и из-за этого происходят проблемы .

На рабочих местах и стоит по одному компьютеру, и одному дисплею или двум дисплеям. Даже если есть один компьютер и 2 дисплея, я получаю две записи, а не 4, как Вы, уважаемый, утверждаете. Но комбинации начинаются тогда, когда не один тип устройства, а несколько разных могут быть использованы с одним компьютером.
- К коммпьютеру можно подключить 2 дисплея, или по вашему нельзя?
- К компьютеру можно подключить 2 и более принтеров, сканеров, или опять таки нельзя?
- За одним компьютером могут работать 2 и более человека в разное время, или опять скажете, что нельзя?

Теперь рассмотрите следующие комбинации:
- компьютер, первый дисплей, пользователь 1,
- компьютер, первый дисплей, пользователь 2,
- компьютер, второй дисплей, пользователь 1,
- компьютер, второй дисплей, пользователь 2
Хотите строго указать каждому из пользователей пользоваться только "своим" дисплеем?

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

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

К сожалению GROUP_CONCAT в купе с DISTINCT не совсем правильные даёт результаты для не ключевых полей.
Я остановился на использовании UNION, как самом быстром получении данных и последующей обработкой результата вне SQL.

А в желаемом виде, к сожалению, от меня начальство потребовало результаты, чтобы не смотреть лишние строчки.

Спасибо, большое, за участе!

Отредактированно dimkainc (28.02.2011 17:14:36)