| Автор |
Сообщение |
|
Сообщение создано: 09. 06. 2016 [15:27]
|
|
s-s-n
s-s-n
Создатель темы
Зарегистрирован(а) с: 16.08.2011
Сообщения: 83
|
Редактирование таблицы своей структуры созданной без PRIMARY KEY.
Если в окне системного конфигуратора, то выходит эта ошибка.
При выполнении запроса SQLReq все проходит нормально.
Вложенный файл
|
|
Сообщение создано: 09. 06. 2016 [15:52]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
Не новость, ключ создавайте!
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 09. 06. 2016 [16:03]
|
|
s-s-n
s-s-n
Создатель темы
Зарегистрирован(а) с: 16.08.2011
Сообщения: 83
|
"roman" wrote:
Не новость, ключ создавайте!
Понял. Если придется когда-то так редактировать, то буду ключ делать.
|
|
Сообщение создано: 11. 10. 2016 [10:39]
|
|
s-s-n
s-s-n
Создатель темы
Зарегистрирован(а) с: 16.08.2011
Сообщения: 83
|
Доброго дня!
Заметил такую штуку.
Если работа OpenSCADA завершается при выключении ПК, то после перезагрузки ПК - скада не видит архиватор значений на БД. БД MySQL.
После перезапуска скады - цепляет его.
С чем такое может быть связано?
|
|
Сообщение создано: 11. 10. 2016 [10:44]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"s-s-n" wrote:
Если работа OpenSCADA завершается при выключении ПК, то после перезагрузки ПК - скада не видит архиватор значений на БД. БД MySQL.
После перезапуска скады - цепляет его.
С чем такое может быть связано?
С менеджером сеансов DE и MySQL тут не к чему вообще.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 11. 10. 2017 [08:49]
|
|
s-s-n
s-s-n
Создатель темы
Зарегистрирован(а) с: 16.08.2011
Сообщения: 83
|
Добрый день, Роман.
Возникла необходимость сделать отчет за произвольную дату.
Столкнулся с очень медленным выполнением запроса. СУБД MySQL.
Что из скады, что из консоли.
После добавления индекса по полю времени скорость выросла в десятки раз!
Не мешало бы добавить автосоздание индексов.
Сейчас архивы на несколько лет, может есть смысл добавить поля(год, месяц, день года) и их индексировать?
Все таки поиск в БД должен быть быстрым...
|
|
Сообщение создано: 11. 10. 2017 [09:05]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"s-s-n" wrote:
Возникла необходимость сделать отчет за произвольную дату.
Столкнулся с очень медленным выполнением запроса. СУБД MySQL.
Что из скады, что из консоли.
После добавления индекса по полю времени скорость выросла в десятки раз!
Не мешало бы добавить автосоздание индексов.
Сейчас архивы на несколько лет, может есть смысл добавить поля(год, месяц, день года) и их индексировать?
Все таки поиск в БД должен быть быстрым...
У меня нет проблем с производительностью архивов на СУБД: http://wiki.oscada.org/Doc/DBArch#h581-6, производительность MySQL.
P.S. Если-же Вам такое нужно то и добавьте, за одно и увидите почему это сложно и не будете предлагать другим такое делать.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 11. 10. 2017 [10:11]
|
|
s-s-n
s-s-n
Создатель темы
Зарегистрирован(а) с: 16.08.2011
Сообщения: 83
|
"roman" wrote:
"s-s-n" wrote:
Возникла необходимость сделать отчет за произвольную дату.
Столкнулся с очень медленным выполнением запроса. СУБД MySQL.
Что из скады, что из консоли.
После добавления индекса по полю времени скорость выросла в десятки раз!
Не мешало бы добавить автосоздание индексов.
Сейчас архивы на несколько лет, может есть смысл добавить поля(год, месяц, день года) и их индексировать?
Все таки поиск в БД должен быть быстрым...
У меня нет проблем с производительностью архивов на СУБД: http://wiki.oscada.org/Doc/DBArch#h581-6, производительность MySQL.
P.S. Если-же Вам такое нужно то и добавьте, за одно и увидите почему это сложно и не будете предлагать другим такое делать.
Запустил тест. Говорит пройден....
Проблема в скорости выполнении запроса к БД с миллионами записей. А выбрать надо всего несколько.
Так добавил индекс, увидел разницу потому и написал.
В чем сложности не понял?
|
|
Сообщение создано: 11. 10. 2017 [10:21]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"s-s-n" wrote:
Запустил тест. Говорит пройден....
Проблема в скорости выполнении запроса к БД с миллионами записей. А выбрать надо всего несколько.
Так добавил индекс, увидел разницу потому и написал.
В чем сложности не понял?
Где патч и протокол проверки для всего разнообразия ситуаций создания, проверки, исправления таблиц c разрешением возможных коллизий индексного поля с возможными рабочими?
Ну и конечно контакты, чтобы я потом все запросы о проблемах там перенаправлял Вам.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 11. 10. 2017 [11:08]
|
|
s-s-n
s-s-n
Создатель темы
Зарегистрирован(а) с: 16.08.2011
Сообщения: 83
|
"roman" wrote:
Где патч и протокол проверки для всего разнообразия ситуаций создания, проверки, исправления таблиц c разрешением возможных коллизий индексного поля с возможными рабочими?
Когда искал причину добавил те индексы к готовым таблицам. Не в исходниках.
Они уже и с данными были. Проблем не возникло.
А проверки на все множество ситуаций? Так ситуаций может бесконечно много - все не проверить никому, а индексы и созданы для оптимизации поиска.
Тут же не надо индексировать текст и прочую экзотику, а обычное целое число.
|
