|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
Есть несколько таблиц, в которых хранится много однотипных значений. Типа такой Код: SQL 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49.
Возникла хотелка подменять отдельные значения по минимуму / максимуму. То есть, для определенного столбца (не для всех) определить минимум и максимум, и если реальное значение выходит за рамки, то возвращать пользователю допустимые минимум или максимум. Эту подмену мы можем делать в трех местах. На стадии вставки данных в таблицу, на стадии хранения (по заданию), на стадии запроса. Если на стадии вставки, то это триггер, и в нем опять же будет динамика. Если на стадии хранения, то вообще ничего сложного, лопать себе да лопать, начиная с последнего места. Единственный минус - задержки в обработке данных. Если на стадии выдачи данных пользователю - самое интересное. И самое вкусное, поскольку исходные данные остаются нетронутыми на тот случай, когда их надо будет посмотреть. Я помню, мне многие советовали не хранить данные горизонтально, но мне до сих пор кажется дикостью хранить такое количество данных вертикально. ЗЫ За пол-года базешка уже за 5 гигов перевалила, и это только тренировка. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2023, 12:03 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
Есть несколько таблиц, в которых хранится много однотипных значений. Типа такой Код: SQL 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49.
Возникла хотелка подменять отдельные значения по минимуму / максимуму. То есть, для определенного столбца (не для всех) определить минимум и максимум, и если реальное значение выходит за рамки, то возвращать пользователю допустимые минимум или максимум. Эту подмену мы можем делать в трех местах. На стадии вставки данных в таблицу, на стадии хранения (по заданию), на стадии запроса. Если на стадии вставки, то это триггер, и в нем опять же будет динамика. Если на стадии хранения, то вообще ничего сложного, лопать себе да лопать, начиная с последнего места. Единственный минус - задержки в обработке данных. Если на стадии выдачи данных пользователю - самое интересное. И самое вкусное, поскольку исходные данные остаются нетронутыми на тот случай, когда их надо будет посмотреть. Я помню, мне многие советовали не хранить данные горизонтально, но мне до сих пор кажется дикостью хранить такое количество данных вертикально. ЗЫ За пол-года базешка уже за 5 гигов перевалила, и это только тренировка. Это не база данных. Хранить то можно, запросы сделать не возможно. И не рационално место и индексы используются. ... |
|||
:
Изменено: 15.03.2023, 19:42 - Sparrow
Нравится:
Не нравится:
|
|||
15.03.2023, 19:31 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
Нужно вникнуть в предметную область, что там хранится и зачем? Не бывет абстрактных баз, это тупиковый путь. Бывают конкретные. Так не бывает, что к одному ключу много значений. ... |
|||
:
Изменено: 15.03.2023, 19:42 - Sparrow
Нравится:
Не нравится:
|
|||
15.03.2023, 19:33 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
что там хранится и зачем? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2023, 19:43 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
Вообще это похоже на олап. Надо в экселе такое делать или во внешнем клиенте, если он не знает , что хочет. Дать данные там пусть работает , но это дорого, с точки зрения sql. Обычно олап кубы ночью готовят, утром дают. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2023, 19:47 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
Есть несколько таблиц, в которых хранится много однотипных значений. Типа такой Код: SQL 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49.
Возникла хотелка подменять отдельные значения по минимуму / максимуму. То есть, для определенного столбца (не для всех) определить минимум и максимум, и если реальное значение выходит за рамки, то возвращать пользователю допустимые минимум или максимум. Эту подмену мы можем делать в трех местах. На стадии вставки данных в таблицу, на стадии хранения (по заданию), на стадии запроса. Если на стадии вставки, то это триггер, и в нем опять же будет динамика. Если на стадии хранения, то вообще ничего сложного, лопать себе да лопать, начиная с последнего места. Единственный минус - задержки в обработке данных. Если на стадии выдачи данных пользователю - самое интересное. И самое вкусное, поскольку исходные данные остаются нетронутыми на тот случай, когда их надо будет посмотреть. Я помню, мне многие советовали не хранить данные горизонтально, но мне до сих пор кажется дикостью хранить такое количество данных вертикально. ЗЫ За пол-года базешка уже за 5 гигов перевалила, и это только тренировка. потом джойни только нужные таблички ... |
|||
:
Изменено: 15.03.2023, 19:57 - Гарыныч
Нравится:
Не нравится:
|
|||
15.03.2023, 19:56 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
что там хранится и зачем? Тогда , да надо 2 базы. Одна сырые данные значений и редких запросов , но долгих. А другая, для типичных 90% запросов, там на процеесе загрузки или ночью, все нормализовать. Собрать суммы. Если критичен ОЛАП, кубы , Надо думать. Так и не скажу сразу. ... |
|||
:
Изменено: 15.03.2023, 19:58 - Sparrow
Нравится:
Не нравится:
|
|||
15.03.2023, 19:57 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
Есть несколько таблиц, в которых хранится много однотипных значений. Типа такой Код: SQL 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49.
Возникла хотелка подменять отдельные значения по минимуму / максимуму. То есть, для определенного столбца (не для всех) определить минимум и максимум, и если реальное значение выходит за рамки, то возвращать пользователю допустимые минимум или максимум. Эту подмену мы можем делать в трех местах. На стадии вставки данных в таблицу, на стадии хранения (по заданию), на стадии запроса. Если на стадии вставки, то это триггер, и в нем опять же будет динамика. Если на стадии хранения, то вообще ничего сложного, лопать себе да лопать, начиная с последнего места. Единственный минус - задержки в обработке данных. Если на стадии выдачи данных пользователю - самое интересное. И самое вкусное, поскольку исходные данные остаются нетронутыми на тот случай, когда их надо будет посмотреть. Я помню, мне многие советовали не хранить данные горизонтально, но мне до сих пор кажется дикостью хранить такое количество данных вертикально. ЗЫ За пол-года базешка уже за 5 гигов перевалила, и это только тренировка. потом джойни только нужные таблички ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2023, 20:18 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
Вау. Интересно. Подумаю. когда кому-то из бухгалтеров надо было поднять данные за предудущие года...., тогда джойнил те, что нужны ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2023, 20:23 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
Есть несколько таблиц, в которых хранится много однотипных значений. Типа такой Код: SQL 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49.
Возникла хотелка подменять отдельные значения по минимуму / максимуму. То есть, для определенного столбца (не для всех) определить минимум и максимум, и если реальное значение выходит за рамки, то возвращать пользователю допустимые минимум или максимум. Эту подмену мы можем делать в трех местах. На стадии вставки данных в таблицу, на стадии хранения (по заданию), на стадии запроса. Если на стадии вставки, то это триггер, и в нем опять же будет динамика. Если на стадии хранения, то вообще ничего сложного, лопать себе да лопать, начиная с последнего места. Единственный минус - задержки в обработке данных. Если на стадии выдачи данных пользователю - самое интересное. И самое вкусное, поскольку исходные данные остаются нетронутыми на тот случай, когда их надо будет посмотреть. Я помню, мне многие советовали не хранить данные горизонтально, но мне до сих пор кажется дикостью хранить такое количество данных вертикально. ЗЫ За пол-года базешка уже за 5 гигов перевалила, и это только тренировка. потом джойни только нужные таблички ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2023, 20:26 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
Есть несколько таблиц, в которых хранится много однотипных значений. Типа такой Код: SQL 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49.
Возникла хотелка подменять отдельные значения по минимуму / максимуму. То есть, для определенного столбца (не для всех) определить минимум и максимум, и если реальное значение выходит за рамки, то возвращать пользователю допустимые минимум или максимум. Эту подмену мы можем делать в трех местах. На стадии вставки данных в таблицу, на стадии хранения (по заданию), на стадии запроса. Если на стадии вставки, то это триггер, и в нем опять же будет динамика. Если на стадии хранения, то вообще ничего сложного, лопать себе да лопать, начиная с последнего места. Единственный минус - задержки в обработке данных. Если на стадии выдачи данных пользователю - самое интересное. И самое вкусное, поскольку исходные данные остаются нетронутыми на тот случай, когда их надо будет посмотреть. Я помню, мне многие советовали не хранить данные горизонтально, но мне до сих пор кажется дикостью хранить такое количество данных вертикально. ЗЫ За пол-года базешка уже за 5 гигов перевалила, и это только тренировка. потом джойни только нужные таблички ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2023, 20:27 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
Это опять динамик sql, так не чесно. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2023, 20:31 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
Это опять динамик sql, так не чесно. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2023, 20:35 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
Есть язоковые фитчи чтобы это делать без динамик sql, если это в пределах нормальных форм. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2023, 20:36 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
Есть язоковые фитчи чтобы это делать без динамик sql, если это в пределах нормальных форм. Sql запрос они могут оптимизировать, там пишешь , что хочешь, а не так как нужно , с тчки зрения Тебя. Меня. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2023, 20:44 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
я них не понил, можешь пояснить? Sql запрос они могут оптимизировать, там пишешь , что хочешь, а не так как нужно , с тчки зрения Тебя. Меня. ... |
|||
:
Изменено: 15.03.2023, 20:48 - Гарыныч
Нравится:
Не нравится:
|
|||
15.03.2023, 20:47 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
воробышку:
То есть, одно снятие показаний - одна метка времени и 60 значений. Снятие может быть раз в две секунды. При выборке нужно только время. Отбора по показаниям нет. ... |
|||
:
Изменено: 15.03.2023, 20:49 - Гарыныч
Нравится:
Не нравится:
|
|||
15.03.2023, 20:49 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
не, ты не демагог.... просто вычислительные ресурсы у всех разные.... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2023, 20:51 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
воробышку:
То есть, одно снятие показаний - одна метка времени и 60 значений. Снятие может быть раз в две секунды. При выборке нужно только время. Отбора по показаниям нет. V1, v2, v3, v4 .... Тем более если несклько таблиц. Они все чегото обозначают. И имеют какието связи. Может там все секретно. Мне не понятно. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2023, 20:58 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
Это по любому много датчиков, они имеют свои иды, свойства. И не возможно с них снять все значения одновременно. Модель мягко говоря сильно абстрактна или упрощена. ... |
|||
:
Изменено: 15.03.2023, 21:09 - Sparrow
Нравится:
Не нравится:
|
|||
15.03.2023, 21:07 |
|
Нужно нестандартное решение
|
|||
---|---|---|---|
#18+
Это по любому много датчиков, они имеют свои иды, свойства. И не возможно с них снять все значения одновременно. Модель мягко говоря сильно абстрактна или упрощена. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2023, 21:18 |
|
|
start [/forum/topic.php?fid=17&msg=326258&tid=8144]: |
0ms |
get settings: |
20ms |
get forum list: |
14ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
46ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
1372ms |
get tp. blocked users: |
3ms |
others: | 35ms |
total: | 1517ms |
0 / 0 |