Ок, но есть объяснение, у которого вероятность 99,99%, потому что оно подтверждено самим же автором изначально, хотя он этого и не осознает. А есть объяснения, вероятность которых <0,01%
Можно их не исключать, хорошо. Но почему им уделяется внимания на порядок больше, чем нормальному объяснению?))
Я лично всего лишь хочу понять, зачем натягивать сову на глобус, выдумывая объяснения, вероятность которых стремится к нулю, в случае, когда просто очередной мамкин трейдер, не понимая вообще, чего он делает, проторговался на (крипто-)бирже и побежал стричь лайки на все возможные площадки.
Это возвращает меня к изначальному вопросу "По вашему СУБД работают?" Именно СУБД. При восстановлении из резервной копии возможна ситуация, что ключи генерируются заново? А как при этом сохраняются внешние ключи? И, возвращаясь к теме топика, так, чтобы только у одного пользователя подменился счет, а не вся система пошла по бороде.
Вы же осознаете, что повышение ставок если и произойдет, то не из кармана агрегатора, а за счет потребителя. Вы, как потребитель, готовы к повышению ставок?
Если ты не работаешь с агрегаторами, то ты не работаешь вообще. Не забывайте про другую сторону - потребителя, который пользуется только агрегаторами, потому что удобно и дешево. Ну и опять же немаловажный фактор - длина очереди штрейкбрехеров. Рыночек-с...
По вашему СУБД работают так, что по сбою/скачку напряжения возможна ситуация, что внутри страницы волшебным образом один валидный внешний ключ заменился на другой валидный внешний ключ строго по одному пользователю?
В вашей же таблице (Трейдинг: гипот**и**зы&прогресс) ровно семь строк с датой продажи = 3 марта. Как уже выше пояснили, продажа фьючерса - тоже сделка. В предоставленном поддержкой отчете ровно 7 строк продажи 3 марта, все в убыток. Не наводит на размышления?
Я изучила весь отчет и не нашла ни одной своей сделки (UGP: есть совпадения по активам, но расхождения по датам торговли и суммам). Например, в отчете оператора есть сделки и убытки за 3 марта 2023 года. Но в период со 2 по 7 марта 2023 г. я не торговала.
Прям ни одна сделка не совпадает? Или, быть может, вы не до конца понимаете, чего вы вообще делаете?
Ох уж эти сказочки, ох уж эти сказочники) На стартапе из 3 человек, где аджайл ради аджайла - может быть, а на "взрослых" проектах горизонт планирования - до обеда))
Это нужно, чтобы в конечную цену включить еще один побор, который упадет в чей-то лично карман, как было с платоном, НДС +2%, 1% Михалкову с каждой флешки и компа и т.д. и т.п., больше ни для чего.
Ого, сколько экспрессии)) Прямо чувствуется вся боль от войны с ветряными мельницами))
Все эти NOT NULL, CHECK, EXCLUDE, UNIQUE, PRIMARY/FOREIGN KEY, да даже типы данных - тоже вполне себе "придание смысла данным".
Да нет же, это ограничения отношений. Теория реляционных БД, вот это все. А когда БД начинает лезть в мои данные, анализируя, что там конкретно за строка или число написаны и принимать на основании этого какие-то решения - это бизнес-логика.
PostgreSQL Table Partitioning? С чего вы взяли, что у меня PostgreSQL?
Факт остается фактом: никто в здравом уме не будет использовать это "на коленке написанное решение" во взрослом продакшне. Потому что, во-первых, мы тут хотим абстрагироваться от конкретного движка СУБД и, во-вторых, не понятно, кто все это добро будет поддерживать и развивать? А когда правила поменяются? А как я могу быть уверен, что эти правила не отвалились? А когда пользователь сам захочет эти правила настраивать? А в распределенной базе? И т.д., и т.п.
Ок, но есть объяснение, у которого вероятность 99,99%, потому что оно подтверждено самим же автором изначально, хотя он этого и не осознает. А есть объяснения, вероятность которых <0,01%
Можно их не исключать, хорошо. Но почему им уделяется внимания на порядок больше, чем нормальному объяснению?))
Я лично всего лишь хочу понять, зачем натягивать сову на глобус, выдумывая объяснения, вероятность которых стремится к нулю, в случае, когда просто очередной мамкин трейдер, не понимая вообще, чего он делает, проторговался на (крипто-)бирже и побежал стричь лайки на все возможные площадки.
Это возвращает меня к изначальному вопросу "По вашему СУБД работают?" Именно СУБД. При восстановлении из резервной копии возможна ситуация, что ключи генерируются заново? А как при этом сохраняются внешние ключи? И, возвращаясь к теме топика, так, чтобы только у одного пользователя подменился счет, а не вся система пошла по бороде.
Это не ответ на мой вопрос
Вы же осознаете, что повышение ставок если и произойдет, то не из кармана агрегатора, а за счет потребителя. Вы, как потребитель, готовы к повышению ставок?
Если ты не работаешь с агрегаторами, то ты не работаешь вообще. Не забывайте про другую сторону - потребителя, который пользуется только агрегаторами, потому что удобно и дешево. Ну и опять же немаловажный фактор - длина очереди штрейкбрехеров. Рыночек-с...
Прям уж многие? Можете пример привести, как воспроизвести такую ситуацию? Хотя бы специально
По вашему СУБД работают так, что по сбою/скачку напряжения возможна ситуация, что внутри страницы волшебным образом один валидный внешний ключ заменился на другой валидный внешний ключ строго по одному пользователю?
В вашей же таблице (Трейдинг: гипот**и**зы&прогресс) ровно семь строк с датой продажи = 3 марта. Как уже выше пояснили, продажа фьючерса - тоже сделка. В предоставленном поддержкой отчете ровно 7 строк продажи 3 марта, все в убыток. Не наводит на размышления?
Прям ни одна сделка не совпадает? Или, быть может, вы не до конца понимаете, чего вы вообще делаете?
Я правильно понял, что ваши доказательства - это электронная таблица, которую вы сами же составили вручную?
Но это же не три способа, а один и тот же
Да еклмн!!1 Годик завтра же!)) Чо мне эта напоминалка глаза год мозолила, если есть @Luchnik22?!))
А @gecube еще и read-only... вот и все изменения за годик...
Ох уж эти сказочки, ох уж эти сказочники) На стартапе из 3 человек, где аджайл ради аджайла - может быть, а на "взрослых" проектах горизонт планирования - до обеда))
Это нужно, чтобы в конечную цену включить еще один побор, который упадет в чей-то лично карман, как было с платоном, НДС +2%, 1% Михалкову с каждой флешки и компа и т.д. и т.п., больше ни для чего.
Скорее, кинопаб)
А у меня их два: бакалавр после 4-го курса, и "нормальный" - после 5-го. Мне чего к чему приравняют?)
Атомспейс
О... понял, вопросов более не имею. Извините за беспокойство.
Ого, сколько экспрессии)) Прямо чувствуется вся боль от войны с ветряными мельницами))
Да нет же, это ограничения отношений. Теория реляционных БД, вот это все. А когда БД начинает лезть в мои данные, анализируя, что там конкретно за строка или число написаны и принимать на основании этого какие-то решения - это бизнес-логика.
PostgreSQL Table Partitioning? С чего вы взяли, что у меня PostgreSQL?
Факт остается фактом: никто в здравом уме не будет использовать это "на коленке написанное решение" во взрослом продакшне. Потому что, во-первых, мы тут хотим абстрагироваться от конкретного движка СУБД и, во-вторых, не понятно, кто все это добро будет поддерживать и развивать? А когда правила поменяются? А как я могу быть уверен, что эти правила не отвалились? А когда пользователь сам захочет эти правила настраивать? А в распределенной базе? И т.д., и т.п.
Задача БД хранить данные и позволять мне их эффективно их извлекать. Любое придание смысла этим данным - бизнес-логика.