Проверка селектом сродни генерации id через select max(id)+1

Вроде работает, но в определённый момент вставки становится слишком много

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

кстати слетел только что генератор, бывает само собой такое? просто в FB у меня как-то было

Я в ту пору когда пользовался ib и fb ещё не знал о генераторах, и вообще нихрена не знал. А в postgres такого небывало у меня.

Я в ту пору когда пользовался ib и fb ещё не знал о генераторах, и вообще нихрена не знал. А в postgres такого небывало у меня.

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

Проверка селектом сродни генерации id через select max(id)+1

))

)))))

Из ib сейчас помню только gbak и постоянное обслуживание им бд

Это был аналог вакуума )

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

нельзя было хранимки писать больше 64 Кб

Это вы как Лев Толстой просто ))

))

нельзя было хранимки писать больше 64 Кб

Прикольно, а в каком году это было?

И потом что в 64 кб можно уместить, чтобы не запутаться?

Вроде же подсознательно хочется разбить большой код

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

Добрый день. Ребят есть такой вопрос. Имеется некий mqtt брокер и на него сливают данные с датчиков реалтайме. И имеется база в постгресе которая выводит геоданные на гис портале. Вопрос: можно ли подключить под мою базу с геоданными значения который гонит mqtt брокер?

не очень понятно что хочешь сделать

Прикольно, а в каком году это было?

2007 по-моему. Ну 64 кб это и не много, это полтора экрана текста отформатированного. Вот потом я работал в компании где очень много логики было в БД, так там километровые хранимки )

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

ну все зависит от задачи ))) что за тематика. Я вот работал в области жд грузоперевозок - рейс вагона это табличка в 50 млн строк и 80+- полей. И на этом нужно различные хреновины просчитывать, обороты вагона, циклы и много чего еще. Как не ужимайся но логика такая что при всем желании маленькие процедурки писать не получается. Ну и зачем, mssql нормально хавает большиме

ну все зависит от задачи ))) что за тематика. Я вот работал в области жд грузоперевозок - рейс вагона это табличка в 50 млн строк и 80+- полей. И на этом нужно различные хреновины просчитывать, обороты вагона, циклы и много чего еще. Как не ужимайся но логика такая что при всем желании маленькие процедурки писать не получается. Ну и зачем, mssql нормально хавает большиме

Вангую эксель головного мозга. Т.е. отсутствие знакомства с понятием "нормальная форма".

Вангую эксель головного мозга. Т.е. отсутствие знакомства с понятием "нормальная форма".

а вы в курсе какие характеристики вагона и сколько их?

а вы в курсе какие характеристики вагона и сколько их?

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

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

ну если вы не работали в области крупных грузоперевозок и аналитики которая по этому строится, то вы слишком самоуверенны ))

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

На мой взгляд, чрезмерная самоуверенность имеет место у Вас, и исходит она от бесспорного принятия имеющейся архитектуры. Видите ли, 50М строк на хозяйственную операцю не может говорить о соответствующей сложности хозяйственной операции - не бывает таких операций.

так то таблиц конечно много было, сам вгон, что везет другая таблица, куда везет другая и т.п. никто все что попало в одну не пихает естествнно, но сути дела не меняет

На мой взгляд, чрезмерная самоуверенность имеет место у Вас, и исходит она от бесспорного принятия имеющейся архитектуры. Видите ли, 50М строк на хозяйственную операцю не может говорить о соответствующей сложности хозяйственной операции - не бывает таких операций.

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

Человек спросил почему такие большие хранимки получаются, я рассказал историю злого инетрпрайза

А спор получается беспредметный

надо брать конкретную задачу и разбирать

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

сломалось всё, когда в mssql на лимит колонок наступили, кажись

о о поперло обсуждение, нук навались народ ))))

разворачивали в адекватную схему

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

Конечно, миллионы мух не могут ошибаться. Я сделал вывод о неоптимальности и более того - бестолковости имеющейся архитектуры БД на основе своего представления о решаемых задачах. Это, бесспорно, самоуверенный подход. Но - зная, как обычно проектируются базы в условиях, когда заказчик сам с трудом ориентируется в собственных процессах - думаю, имею полное право на такое воззрение.

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

ну это жестоко )

сломалось всё, когда в mssql на лимит колонок наступили, кажись

ААААА!!!11111

но это целая хранимка была, чтобы такое апдейтить

Конечно, миллионы мух не могут ошибаться. Я сделал вывод о неоптимальности и более того - бестолковости имеющейся архитектуры БД на основе своего представления о решаемых задачах. Это, бесспорно, самоуверенный подход. Но - зная, как обычно проектируются базы в условиях, когда заказчик сам с трудом ориентируется в собственных процессах - думаю, имею полное право на такое воззрение.

кхм кхм, ну заказчик то собственно мы сами, люди которые работают на железной дороге )))

ну не я работал, учредители

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

да да не удивляйтесь, есть такая должность на ЖД - советник ))

но это целая хранимка была, чтобы такое апдейтить

Я, помнится, когда еще сисадминил, скриптовал установку элементов Nero как демо, нарезку болванки и снос этих элементов месте со следами демо :)

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

Вы не пробовали получить от этих лиц определение второй нормальной формы базы данных?

я вот тоже могу сванговать что самые интересные данные которые у вас были это информация о товаре в интернет магазине)

ой, да ладно вам, регулярно пишу и сношу хранимки на три экрана

я вот тоже могу сванговать что самые интересные данные которые у вас были это информация о товаре в интернет магазине)

Вот, Вы сейчас продемонстрировали поведение, полностью аналогичное моему. Что говорит о том, что моя реакция на приведенные Вами данные нормальна и ожидаема :)

Вот, Вы сейчас продемонстрировали поведение, полностью аналогичное моему. Что говорит о том, что моя реакция на приведенные Вами данные нормальна и ожидаема :)

не ну а сколько можно про нормальные формы )))

вы так договоритесь до того, что дёргать http из запроса ненормально

не ну а сколько можно про нормальные формы )))

До наступления у пациента понимания нормальных форм.

вы так договоритесь до того, что дёргать http из запроса ненормально

С точки зрения психиатрии - безусловно!

а ну понятно ))) вечер поговорить нескем )

а ну понятно ))) вечер поговорить нескем )

А Вам?

Чет все больше вспоминается, где были куплены первые сваровски

А Вам?

ды вроде тоже, но не продуктивно как-то получается)

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

ну а табличка в 80+ колонок в логистике вообще дело обычное

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

+

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

Работает - не трогай :)

после такого баттла, как то неловко задавать вопросы :)

ERROR: S client not available

Но, всетаки задам: Насколько правильно использвать в бэкенде такие фокусы для выгрузки данных: Copy (Select * From foo) To '/var/www/mysqite.loc/export/test.csv' With CSV DELIMITER ',';

Ну а вам как кажется? Учитывая выполнение COPY на стороне сервера БД? Не портабельно однако

Вопрос

Вопрос: Есть поток данных с частотой обновления в 1 секунду, можно ли писать лог работы сервера с привязкой ко времени и значением в каждую секунду времени? а этот лог использовать как БД для построения графика (температура, давление)

Вопрос: Есть поток данных с частотой обновления в 1 секунду, можно ли писать лог работы сервера с привязкой ко времени и значением в каждую секунду времени? а этот лог использовать как БД для построения графика (температура, давление)

Вопрос в чем? Можно ли вставлять данные каждую секунду?

Но, всетаки задам: Насколько правильно использвать в бэкенде такие фокусы для выгрузки данных: Copy (Select * From foo) To '/var/www/mysqite.loc/export/test.csv' With CSV DELIMITER ',';

Это случаем не ETL? Там обычная практика делать всякие copy. Типичный кейс выгрузка для внешних bi и прочих olap

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

Вопрос в чем? Можно ли вставлять данные каждую секунду?

вот

Вам time-series данные хранить надо?

если так, то почему не делать выборку сразу из БД? вы же уже положили туда данные

Но, при большом объеме таблиц, быстродействие будет не особо впечатляющим )

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

если так, то почему не делать выборку сразу из БД? вы же уже положили туда данные

данные у объекта меняются каждую секунду

у вас постоянные update?

да, частота 1 сек

почему не INSERT? По производительности одинаково, но можно хранить историю

для тест 1 таблица 2 параметра 2 столбца

да, частота 1 сек

Зачем?

снимать показания температуры

INSERT быстрее даже )

влажности

Делаете инсерты и партиции по времени.

согласен. Партицирование - то что надо учитывая параллельный сиквенс скан в 9.6

Делаете инсерты и партиции по времени.

Потом можете выгружать эти партиции и удалять если не нужны.

триггер можно по тому же timestamp сделать

простое и надежное решение получится

триггер можно по тому же timestamp сделать

Ну да, только условие партиции выбрать правильно.

сюда можно код кидать? )

Ну да, только условие партиции выбрать правильно.

По суткам разбивать или по неделям например. Зависит от размера данных.

мне нужно что бы в реалтайме графики отображались

Stanislav используйте тогда KV хранилища типа редиса как кеш