Для создания опердени требуется хранить деньги в БД. А БД не простая, а гугловская. Т.е. Decimal - нет, но есть integer, float и string.
Хранить во флот - потеря точности + странные суммы вроде 2.000000009 В стринге - придется делать свои математические операции. Можно и в ineger хранить в виде коппек, а при выводе просто делить на 100. пока склоняюсь к этому варианту.
вот это-то понятно, вопрос в том как много этих операций? просто из того, что я читал по проектированию хранения данных "на века" - как раз стринг и рекомендуют, но там не для БД, правда. потому и спросил.
Того кто рекомендует стринг, нужно поставить в угол и избивать по голове hard-cover изданием TAPL бенджамина пирса, до тех пор, пока не поймет, зачем люди придумали строгую типизацию. Я таки насмотрелся решений вида "храним произвольные данные в БД, сериализуя их в строку", иногда это приемлемо, но если есть возможность так не делать - лучше так не делать)
спасибо за наводку ребе - гляну краем глаза. но я специально выделил - там рекомендация не для БД. Скорее для файлов со структурами, конфигов, высокоуровневывых протоколов - для последних двух особенно хорошо, как показывает мой скромный опыт. с файлами-хранилищами и БД не работаю - поэтому и стало интересно - а как там у "них"? ;-)
Да, для этого всего лучше текст, если нету жестких ограничений по памяти, производительности и трафику. И все равно - желательно оный текст строго типизировать, т.е. в памяти оно все равно будет в виде кошерных структур данных, а не строк.
а я вот недавно, наоборот, постановил передавать числа в json именно в строках. А всё почему? Потому что числа в json плохие, негодные. Таким же образом могут обстоять дела и в других "окружениях" -- в субедешечьках, например.
Кроме того, содержимое произвольного типа можно запихнуть в строку, тем не менее оставляя строгую типизацию. Просто она будет динамической, но от того не менее строгой.
ну если вся база (точнее хранищище) -- oid -> object, оно и получается int64 -> serialized (Но там свой рак индексов на application уровне, и zodb головного мозга)
Зато туда можно нахреначить практически любой граф (хоть цикличный)
Можно еще создать круг "strange people" -- и добавить туда пару десятков дико популярных блоггеров, и пару десятков унылых задротов, чтобы гугловый датамайнер тоже малость сломался
Внезапный вопрос.
А БД не простая, а гугловская. Т.е. Decimal - нет, но есть integer, float и string.
Хранить во флот - потеря точности + странные суммы вроде 2.000000009
В стринге - придется делать свои математические операции.
Можно и в ineger хранить в виде коппек, а при выводе просто делить на 100. пока склоняюсь к этому варианту.
Что пауки думают по этому поводу?
Re: Внезапный вопрос.
Вообще интегер безальтернативен, вопрос только в диапазоне значений.
Re: Внезапный вопрос.
Re: Внезапный вопрос.
Re: Внезапный вопрос.
просто из того, что я читал по проектированию хранения данных "на века" - как раз стринг и рекомендуют, но там не для БД, правда. потому и спросил.
Re: Внезапный вопрос.
Я таки насмотрелся решений вида "храним произвольные данные в БД, сериализуя их в строку", иногда это приемлемо, но если есть возможность так не делать - лучше так не делать)
Re: Внезапный вопрос.
но я специально выделил - там рекомендация не для БД. Скорее для файлов со структурами, конфигов, высокоуровневывых протоколов - для последних двух особенно хорошо, как показывает мой скромный опыт.
с файлами-хранилищами и БД не работаю - поэтому и стало интересно - а как там у "них"? ;-)
Re: Внезапный вопрос.
Re: Внезапный вопрос.
Кроме того, содержимое произвольного типа можно запихнуть в строку, тем не менее оставляя строгую типизацию. Просто она будет динамической, но от того не менее строгой.
Re: Внезапный вопрос.
(Но там свой рак индексов на application уровне, и zodb головного мозга)
Зато туда можно нахреначить практически любой граф (хоть цикличный)
Re: Внезапный вопрос.
Re: Внезапный вопрос.
а вообще в институте должны были научить что деньги хранятся в типе с фиксированной десятичной точкой
Re: Внезапный вопрос.
no subject
no subject
no subject
no subject
Потом оказывается что это в основном ЖЖные френды, которых только под никами знал, а тут realnames.
no subject