Почему MS SQL по разному форматирует даты?

Тут и возникает интересный момент. Если формат вот такой
2017-11-01
То на моей машине у меня дата преобразовывается к формату 01.11.2017
А на других не преобразовывается.

Блин не сразу заметил, вы в обоих случаях делаете запросы через делфи? Тогда это настройки окружения делфи и sql server тут не при чем

Почему MS SQL по разному форматирует даты?

krka92, Вы делаете запрос к одной и той же базе данных и одной и той же таблице, в обоих случаях через консоль(только разные машины) и оба случая возвращают разные форматы дат, так?

Почему MS SQL по разному форматирует даты?

krka92,

ЗЫ
В базе только в некоторых таблицах такие форматы дат 2017-11-01
В остальных 01.11.2017

Так может причина именно в этом, что вы делали запросы к разным таблицам, и они возвращались в тех форматах, в которых были в базе?

Почему MS SQL по разному форматирует даты?

krka92, я правильно понимаю, что у вас есть две разные машины, и вы с обеих делаете запрос лишь к одному экземпляру, который на одной из этих двух машин? Покажите структуру таблицы, в которой хранится дата, и запрос, который возвращает разные форматы

Почему MS SQL по разному форматирует даты?

krka92, покажите код, который возвращает даты в разных форматах

Почему MS SQL по разному форматирует даты?

krka92, это нормально. Если нужен определенный формат, то делаете как я указал выше и дело сделано

Стоит ли идти в разработку под IOS(swift)? Junior'ы никому не нужны?

Рональд Макдональд,

Я знаю о чем говорю не понаслышке: многие студии(особенно провинциальные) используют подход набора джунов за еду, которых обучают за месяц два клепать интернет магазины и дело сделано - речь шла об этом вебе. Если же говорить про нечто серьезное(веб в серьезных проектах) - там ситуация идентична ситуации в других направлениях. Если есть что по существу и конструктивного сказать - буду рад ознакомиться с противоположной точкой зрения. "Дальше не читал" - в этом мало конструктива

В какую разработку еще можно успеть войти помимо web?

Не знаю как 1С, но в андроид лучше не лезь, оно тебя сожрет. Знаний нужно неадекватно много, вакансий джунов нет(в отличие от того же веба), ну а чтобы быть миддлом вам нужно знать столько всего и успевать за стольким, что лучше вам не знать.

Зачем делают ID в формате sha1?

Melkij,

Пришло время добавить новый шард. Действия? Перебалансируем всё? А если не хотим даунтайм на перебалансирование - то требуем места на дисках вдвое больше?

Ничего из этого не нужно. Необходимо с самого начала создать настолько много шардов, сколько вообще может потребоваться, хоть несколько тысяч. И прелесть в том, что они все могут крутиться всего на одном физическом серваке в начале. Как только количество пользователей увеличивается и на сервер уже приличная нагрузка, то половину шардов перекидываем на другой физический сервак, тем самым снизив нагрузку в 2 раза. И таким образом можно масштабироваться до момента, когда на каждый физический сервер будет приходиться по одному шарду. То есть если мы изначально создадим, например, 1024 шарда, то можно будет расти до очень больших объемов. Все это контролировать можно по разному, самый очевидный вариант это табличка в которой указано, какой шард на каком физическом серваке находится.

Как передаёте логин при последующих запросах? После авторизации?

Как уже говорил, нужно использовать токены, например, jwt. Все что в этом случае нужно передавать - это токен. И этого токена достаточно, чтобы идентифицировать пользователя.

И, главное, - если считаем хэш от логина - зачем вам uuid или хэш первичным ключом? Зачем вам вообще его хранить? Вы по нему вовсе не ищете, вы его вычисляете от логина и так понимаете куда с этим логином идти.

Хеш по сути не нужно хранить - он вычисляется чтобы просто понять на какой шард идти. А вот uuid нужен чтобы обеспечить уникальность по всей базе данных. Мы же не хотим иметь например пользователей с одинаковым id в разных шардах? Да, в данный момент шард для каждого юзера свой, но а если в дальнейшем нужно будет как-то слить все данные в одно место, зачем нам эти конфликты с одинаковыми id? Да и логически это неправильно - ведь логически мы должны рассматривать распределенную базу как единое целое, и все идентичные таблицы на разных шардах должны рассматриваться как части единого целого, а значит нужно обеспечить уникальность.

В кейсе автора вопроса использовали хеш в качестве uuid и я считаю это отличным решением, одной пулей двух зайцев. Единственное, я не понял, как они уместили 20-ибайтный хеш в 16-ибайтный uuid. Надеюсь, они не хранят в varchar.

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

Зачем создавать бутылочное горлышко? Это выбивается из концепции равномерного распределения. На каждом шарде должна быть одинаковая структура базы данных.

А там окажется что данные чуть ли не с запуска проекта уже сильно связанные и легко шардироваться всё равно не можете. Или что шардировать надо было вовсе по другому признаку.

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

В целом я согласен с Вами, что в 95%(а может и больше) случаев это все будет лишним и большинство проектов не перерастут даже пары-тройки мощных серверов. Но, тем не менее, если вы делаете проект, который своей целью ставит большое количество пользователей и данных, то на мой взгляд обязанность инженера создать все необходимые условия. Насколько я понял вы DBA и я понимаю, сколько все эти манипуляции доставляют вам боли, ведь поддержка всего этого не самая тривиальная задача. Ну и так же понимаю насколько это обидно, когда тратишь кучу сил на это, а оно в итоге просто оказывается ненужным. Тем не менее, если бизнес требует и нацелен на что-то, мы должны делать так, чтобы все легко и плавно масштабировалось.

Зачем делают ID в формате sha1?

Melkij, нажимайте пожалуйста "Ответить", чтобы я получал уведомления.

Обычным bigint.

Так речь же шла о том, чтобы генерировать uuid. Вы сказали про производительность, а я упомянул возможность генерации последовательных uuid, которые в производительности не сильно уступают обычным числовым идентификаторам.

На счёт шардинга: искать нужный шард можно по проверенной и многими любимой схеме - вычисляем хеш от логина/телефона -> берём остаток по модулю на количество шардов -> получили нужный шард. Сессий никаких не надо - токены дадут независимость. Уникальность логина нужно проверять в любом случае по всей системе.

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

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

К вычисляемому столбцу вы вряд ли сможете обратиться. Но что мешает добавить этот столбец в таблицу? Тогда все заработает

Как парсить html, который постоянно видоизменяется/морфируется (структура, теги, классы и т.д.) при каждом запросе?

Чувак, у которого не вышло с английским на тостере, решил зайти с другого фланга

Создание MVP (web-app по типу Reddit) на базе конструкторов, фреймворков - какое решение оптимальное?

Alex Dmn, да, ну и wordpress гляньте, может и там что подходящее найдется

Создание MVP (web-app по типу Reddit) на базе конструкторов, фреймворков - какое решение оптимальное?

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

Смена профессии IT Service Manager > ???

Советую прислушаться к ответу.
"Не выходи из комнаты, не совершай ошибку."

Зачем делают ID в формате sha1?

Вон как выше в точности: есть один проект, где это оказалось полезно. Давайте не будем думать что это совершенно не про наш проект, а тупо сделаем так же, ведь те ребята так сделали и вон как выросли.
Самое интересное происходит когда нет осмысленной причины даже не использовать штатный в субд тип данных под uuid, а пихают в varchar(255) какой-нибудь или сразу в text.

Я если честно не сосем понимаю, почему Вы так убеждены, что где-то кому-то это не нужно. Если кто-то пророчит себе нагрузки как у фейсбука и заранее готовится - это его проблемы и фантазии, но мы, программисты, должны смотреть на задачу с точки зрения правильной архитектуры и простоты масштабирования. Если проект заточен под рост, то нужно думать о горизонтальном масштабировании. Лучше предусмотреть возможность и создать все условия, чем потом мучиться. Понятное дело, если кто-то делает интернет магазин с кормом для кошек в городе с населением 100к, то это излишне. Но если кто-то планирует создать масштабный проект, то нужно быть готовым. Я знаю про преждевременную оптимизацию и все такое, но заметьте, я ни слова не сказал о том, чтобы поднять десяток серверов заранее. Просто нужно быть архитектурно готовым к такому сценарию. А на счет "пихают в varchar(255)" - это да, катастрофа, если честно не думаю, что в продакшне такие случаи есть или их очень много, уж очень это грубая ошибка.

Замечательный пример мужественного решения проблем. Вот только раз это функция субд - то и в чём проблема с аналогичным простым сиквенсом?

Обычным сиквенсом, генерирующим uuid?

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

Теперь понял, спасибо.

Как реализуется организация каталога интернет-магазина?

Maksim86, нет, это не описание. Смотрите, для начала скажите, о каких объемах товаров речь. Затем скажите, какая предполагается нагрузка (хотя бы просто сколько пользователей у вас ожидается в один момент времени примерно). Затем скажите, как будет устроен магазин - какие там категории и подкатегории, какая максимальная вложенность, может ли один товар фигурировать в разных категориях/подкатегориях, будут ли делаться выборки товаров смешанных категорий и насколько часто, может это и вовсе основной сценарий, и т.д. То есть вам нужно очень подробно описать задачу, чтобы можно было предложить оптимальное решение.

Как реализуется организация каталога интернет-магазина?

Это довольно классический случай, он называется EAV. Создать можно многими способами - от способов "в лоб и по-быстрому", до правильных и гибких. Также тот или иной способ может оказаться более или менее предпочтительным в зависимости от, например, того, как много будет подкатегорий, как часто они будут добавляться, от нагрузок, сценариев использования и т.д. Слишком много факторов, от которых зависит правильное решение. Поэтому на ваш вопрос невозможно дать однозначный ответ. Если вы более подробно опишете задачу, тогда можно будет помочь.

Зачем делают ID в формате sha1?

ince, от злоумышленников. Например если вы посмотрите на адресную строку сейчас под этим вопросом, то увидите toster.ru/q/659044, где с большой долей вероятности 659044 - это айдишник вопроса в базе данных. В данном случае это нечувствительные данные и ничего страшного в этом нет, но в проектах где есть чувствительные данные часто избегают использования обычных числовых идентификаторов. Ну и помимо открытости - любая система может быть взломана, и если злоумышленник взломал один из уровней, на котором он получил доступ например к закрытому апи базы данных, то он не сможет подобрать айдишники в случае uuid, чтобы извлечь данные.

Зачем делают ID в формате sha1?

- без особой пользы в разы увеличить объём хранимых данных. Тем более если использовать строки.

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

- дополнительно увеличить стоимость записи индексов (значения случайны = значения пишутся в случайные места дерева, вы постоянно "пачкаете" разные страницы)

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

Но если это ключ партицирования - то вы бы и так уже знали почему используется не число.

Раз 5 перечитал я все равно не понял. Можете пожалуйста чуть более подробно сказать, что имеете в виду?