Ну если вы знаете, что скорость одинаковая, при поиске паспортов, напечатанных в заданных пользователем регионах и за определённые года, для хранения единой строкой и для хранения в отдельных полях регион, год, номер, то тогда попрошу предъявить алгоритм поиска.
Но это если bi и начальник Большой
Да нет, просто системы разные бывают. Но у вас паспорт-всегда идентификатор именно человека, даже когда он только в печать пошёл.
Вы серьёзно? Я вообще не о людях думаю, а о назначении системы. Представьте, что бывают системы, которые эти самые паспорта печатают. И там тоже есть номер паспорта. Но к человеку он вообще никак не привязан (поскольку бланк только печатается, даже не напечатан еще). И идентификатор там не номер паспорта, а внутренний Id (поскольку завтра на этой линии вообще не паспорта печатать будут). А ещё есть разные отдельные системы bi, в которых большой начальника хочет данные о напечатанных паспортах проанализировать (сколько чего в каких регионах напечатано было). И вот например для bi могут быть вопросы как хранить(но тоже не обязательно).
Мысль сложная. :) Но с опытом привыкаешь выяснять подробности.
Ну и если почитаете мой первый пост, то там только заметки по скорости обработки стоки и цифры были, а не по хранению.
Просто иногда люди, предлагающие не хранить одной строкой, сначала выясняют все обстоятельства работы системы, взвешивают за и против, а затем уже предлагают. А не просто предлагают сферического коня в вакууме.
С чего вы решили, что в системе номер паспорта будет служить именно идентификатором человека, а не источником данных по отпечатанным бланкам, например?
Ну и я не гарантирую, а говорю, что разделение серии на ОКАТО и год выпуска при вводе и хранении-это один из возможных вариантов использования. И в этом случае есть смысл думать о числовых полях. Разделять или нет-зависит от функций конкретной системы. Если у вас серия и номер паспорта-это просто идентификатор, то нафиг вам числовые поля не сдались. А вот если вы хотите на их основе какой-то анализ строить (без доп полей), то как хранить-зависит от того, что вы анализировать будете.
А вы готовы гарантировать, что ваш where between обеспечит сопоставимую скорость по сравнению с поиском по числам при вводе пользователем 5-8 значений года для поиска? Нигде не напрягает, что мы там подстроки выделять будем?
Ещё раз, в статье правильно сказал автор, что надо думать не только о семантике, но и о возможных условиях использования. Естественно при проектировании надо закладывать возможные сценарии изменения функций.
Мой изначальный пост был про то, что использование использование числовых полей не всегда даёт оверхед при работе. Всё зависит от функций системы, которые вы старательно выводите из обсуждения, заменяя на наиболее частые варианты использования.
Так вопрос-то изначально не про дополнительные поля паспорта. С чего вы решили, что ваша система будет их содержать? Или что она будет с загран паспортами вообще работать? Возможно ваша система-это учёт бланков на госзнаке, где паспорт-вообще один из многих документов.
Я говорю о том, что проектировать хранение данных без учёта их применения вообще не правильно. И да, глупость границ не имеет. В том числе и при проектировании. И да, при проектировании надо всегда закладывать возможность изменения/расширения функциональности.
Мой изначальный пост был о том, что хранение номера паспорта в числовых полях не всегда даст оверхед по сравнению с хранением в строке.
Всех желающих хранить номер серию и номер паспорта одной строкой не думая, как вы их будете использовать, предлагаю найти алгоритм поиска в такой строке паспортов, напечатанных в определённые, задаваемые пользователем, годы. Ну и естественно подумать над вопросом, а нет-ли в таком алгоритме оверхеда при работе со строками.
Формат ОКАТО -это 8-11 цифр. Согласен, что теоретически он может быть изменён. Но сравнивать-то придётся 2 цифры с 8ю. И как следствие придётся хранить сокращённый вариант.
Ещё раз-если идентификатор составной и несёт смысловую нагрузку, то всегда можно придумать задачи по этим смысловым полям.
Я ответил на ваш вопрос: какова семантика данных. А вот какие операции над ними будут проводиться-надо разбирать по конкретной системе и требованиям к ней.
Вы же продолжаете жить в парадигме, что "это просто идентификатор" Ничего кроме поиска по нему целиком не предполагая.
Более того-так происходит почти всегда. Это нормально, когда прошлогодние бланки выдают в следующем году.
Но замените слово "выданные" на "напечатанные" и вот уже запрос имеет практический смысл.
По хорошему идентификатор не должен содержать смысловую нагрузку. А номер паспорта её содержит. А раз так, то можно и задачи на эту нагрузку придумать.
Вы уверовали в то, что номер паспорта-это идентификатор. И забыли ответить на свои же вопросы.
Какова семантика этих данных? (Что они означают?)
Какие операции над ними будут производиться?
Серия паспорта-это весьма информативная составляющая. Первые 2 цифры-это код ОКАТО региона, где паспорт выдан. Вторые-год выпуска бланка. А вот номер паспорта-это как раз уникальный идентификатор.
Исходя из ответа на первый вопрос, я легко могу представить систему, в которой необходимо найти паспорта в определённом регионе, выданные в промежутке между скажем 2009 и 2010 годами.
И в этом случае числовой формат хранения даст более быстрый поиск.
Другое дело, что такого рода системы встречаются реже, чем те, где номер паспорта-просто идентификатор. Но вы же не конкретизировали, какие именно функции предоставляет система, а просто безапелляционно утверждаете, что мы имеем дело с обычным идентификатором.
Это было другое (с) ;) И масштабы, и объекты санкций"
Объекты санкций были примерно одинаковы. Так у Ирана в 1979 заморозили в том числе и активы Центробанка Ирана (золотовалютные резервы, и банковские активы), а также вложения в акции американских компаний. В общем всё, до чего смогли дотянуться.
По объему-да, несколько меньше. На тот момент около 12 млрд долларов. В сегодняшних ценах это около 53 млрд. Меньше, чем у РФ, но в целом вполне сопоставимо. Особенно с учётом разницы размеров населения.
Насчёт выводов, сделанных заинтересованными сторонами, считаю пока говорить рано. Слишком мало времени прошло для определения среднесрочных тенденций.
До России были Иран в 1979 и 2012, Ливия в 2011, Сирия в 2011, Венесуэла в 2019. С точными годами правда могу немного ошибаться, но Россия точно не первая, у кого были подобным образом счета заблокированы.
Я писал безотносительно размера массивов и способов замера времени.
Сравнивать быстродействие надо на одинаковых сценариях. А то, что при использовании массива можно сценарий оптимизировать- ну этот сценарий можно, другой нельзя будет.
Т.е. если говорить об изначальном вопросе (что быстрее циклы или стрелки), то условия эксперимента не корректные. В первом случае автор прогнал 2 последовательных цикла, во втором-один. Вместо чистого эксперимента сделана оптимизация кода и сравнение с оригинальной версией.
На каком уровне права нарезать будете? На уровне каждого отдельного контрола со списком.
Ещё раз, выдумывать выход можно. Нарезать права, и т.п. Но предусмотреть все требования реального заказчика нельзя. Вы меня не услышали. Не надо пытаться ограничивать вариативность разработки.
Ну и плюс кто будет платить за создание и поддержание этих стандартов? Или ваши учёные бесплатно работать будут? И не надо писать про нулевую стоимость разработки, когда библиотеки уже созданы. Сами себя они не создадут. И поддерживать себя сами не будут.
Вы когда-нибудь сталкивались с иб в более-менее серьёзном бизнесе? Я с удовольствием посмотрю, как вы им будете объяснять, что возможность сохранить список, содержащий коммерческую тайну в файл-это оказывается стандарт такой.
Ну а если серьёзно, то что вы предлагаете-это ограничение вариативности разработки. Ну нельзя расписать до молочей все требования, которые в проектах возникают. И наука здесь абсолютно ни причем. Это никому не нужно, ни бизнесу, ни разработчикам, ни пользователям, которые это ви конечном счёте оплачивать будут.
Тут помочь ничем не могу. Грамоте не обучаю.
Так в госуслугах и нет необходимости составные части паспортных данных анализировать.
https://habr.com/ru/articles/1012950/comments/#comment_29702624
Ну если вы знаете, что скорость одинаковая, при поиске паспортов, напечатанных в заданных пользователем регионах и за определённые года, для хранения единой строкой и для хранения в отдельных полях регион, год, номер, то тогда попрошу предъявить алгоритм поиска.
Да нет, просто системы разные бывают. Но у вас паспорт-всегда идентификатор именно человека, даже когда он только в печать пошёл.
Вы серьёзно? Я вообще не о людях думаю, а о назначении системы. Представьте, что бывают системы, которые эти самые паспорта печатают. И там тоже есть номер паспорта. Но к человеку он вообще никак не привязан (поскольку бланк только печатается, даже не напечатан еще). И идентификатор там не номер паспорта, а внутренний Id (поскольку завтра на этой линии вообще не паспорта печатать будут). А ещё есть разные отдельные системы bi, в которых большой начальника хочет данные о напечатанных паспортах проанализировать (сколько чего в каких регионах напечатано было). И вот например для bi могут быть вопросы как хранить(но тоже не обязательно).
Мысль сложная. :) Но с опытом привыкаешь выяснять подробности.
Ну и если почитаете мой первый пост, то там только заметки по скорости обработки стоки и цифры были, а не по хранению.
Просто иногда люди, предлагающие не хранить одной строкой, сначала выясняют все обстоятельства работы системы, взвешивают за и против, а затем уже предлагают. А не просто предлагают сферического коня в вакууме.
С чего вы решили, что в системе номер паспорта будет служить именно идентификатором человека, а не источником данных по отпечатанным бланкам, например?
Точно ОКАТО смотрели? Это не тоже самое, что код региона на номерах машин. Всё паспорта, что я видел строго совпадают.
45 - Москва
40- СПБ
Ну и я не гарантирую, а говорю, что разделение серии на ОКАТО и год выпуска при вводе и хранении-это один из возможных вариантов использования. И в этом случае есть смысл думать о числовых полях. Разделять или нет-зависит от функций конкретной системы. Если у вас серия и номер паспорта-это просто идентификатор, то нафиг вам числовые поля не сдались. А вот если вы хотите на их основе какой-то анализ строить (без доп полей), то как хранить-зависит от того, что вы анализировать будете.
А вы готовы гарантировать, что ваш where between обеспечит сопоставимую скорость по сравнению с поиском по числам при вводе пользователем 5-8 значений года для поиска? Нигде не напрягает, что мы там подстроки выделять будем?
Ещё раз, в статье правильно сказал автор, что надо думать не только о семантике, но и о возможных условиях использования. Естественно при проектировании надо закладывать возможные сценарии изменения функций.
Мой изначальный пост был про то, что использование использование числовых полей не всегда даёт оверхед при работе. Всё зависит от функций системы, которые вы старательно выводите из обсуждения, заменяя на наиболее частые варианты использования.
Так вопрос-то изначально не про дополнительные поля паспорта. С чего вы решили, что ваша система будет их содержать? Или что она будет с загран паспортами вообще работать? Возможно ваша система-это учёт бланков на госзнаке, где паспорт-вообще один из многих документов.
Я говорю о том, что проектировать хранение данных без учёта их применения вообще не правильно. И да, глупость границ не имеет. В том числе и при проектировании. И да, при проектировании надо всегда закладывать возможность изменения/расширения функциональности.
Мой изначальный пост был о том, что хранение номера паспорта в числовых полях не всегда даст оверхед по сравнению с хранением в строке.
Всех желающих хранить номер серию и номер паспорта одной строкой не думая, как вы их будете использовать, предлагаю найти алгоритм поиска в такой строке паспортов, напечатанных в определённые, задаваемые пользователем, годы. Ну и естественно подумать над вопросом, а нет-ли в таком алгоритме оверхеда при работе со строками.
Формат ОКАТО -это 8-11 цифр. Согласен, что теоретически он может быть изменён. Но сравнивать-то придётся 2 цифры с 8ю. И как следствие придётся хранить сокращённый вариант.
Ещё раз-если идентификатор составной и несёт смысловую нагрузку, то всегда можно придумать задачи по этим смысловым полям.
Я ответил на ваш вопрос: какова семантика данных. А вот какие операции над ними будут проводиться-надо разбирать по конкретной системе и требованиям к ней.
Вы же продолжаете жить в парадигме, что "это просто идентификатор" Ничего кроме поиска по нему целиком не предполагая.
Более того-так происходит почти всегда. Это нормально, когда прошлогодние бланки выдают в следующем году.
Но замените слово "выданные" на "напечатанные" и вот уже запрос имеет практический смысл.
По хорошему идентификатор не должен содержать смысловую нагрузку. А номер паспорта её содержит. А раз так, то можно и задачи на эту нагрузку придумать.
Весьма спорное утверждение.
Вы уверовали в то, что номер паспорта-это идентификатор. И забыли ответить на свои же вопросы.
Серия паспорта-это весьма информативная составляющая. Первые 2 цифры-это код ОКАТО региона, где паспорт выдан. Вторые-год выпуска бланка. А вот номер паспорта-это как раз уникальный идентификатор.
Исходя из ответа на первый вопрос, я легко могу представить систему, в которой необходимо найти паспорта в определённом регионе, выданные в промежутке между скажем 2009 и 2010 годами.
И в этом случае числовой формат хранения даст более быстрый поиск.
Другое дело, что такого рода системы встречаются реже, чем те, где номер паспорта-просто идентификатор. Но вы же не конкретизировали, какие именно функции предоставляет система, а просто безапелляционно утверждаете, что мы имеем дело с обычным идентификатором.
Объекты санкций были примерно одинаковы. Так у Ирана в 1979 заморозили в том числе и активы Центробанка Ирана (золотовалютные резервы, и банковские активы), а также вложения в акции американских компаний. В общем всё, до чего смогли дотянуться.
По объему-да, несколько меньше. На тот момент около 12 млрд долларов. В сегодняшних ценах это около 53 млрд. Меньше, чем у РФ, но в целом вполне сопоставимо. Особенно с учётом разницы размеров населения.
Насчёт выводов, сделанных заинтересованными сторонами, считаю пока говорить рано. Слишком мало времени прошло для определения среднесрочных тенденций.
До России были Иран в 1979 и 2012, Ливия в 2011, Сирия в 2011, Венесуэла в 2019. С точными годами правда могу немного ошибаться, но Россия точно не первая, у кого были подобным образом счета заблокированы.
Решаемая задача одна. Сценарий у автора как раз разный.
Одинаковый сценарий был бы например заполнение данных в 1 массиве через лямбду и через цикл.
Я писал безотносительно размера массивов и способов замера времени.
Сравнивать быстродействие надо на одинаковых сценариях. А то, что при использовании массива можно сценарий оптимизировать- ну этот сценарий можно, другой нельзя будет.
Т.е. если говорить об изначальном вопросе (что быстрее циклы или стрелки), то условия эксперимента не корректные. В первом случае автор прогнал 2 последовательных цикла, во втором-один. Вместо чистого эксперимента сделана оптимизация кода и сравнение с оригинальной версией.
На каком уровне права нарезать будете? На уровне каждого отдельного контрола со списком.
Ещё раз, выдумывать выход можно. Нарезать права, и т.п. Но предусмотреть все требования реального заказчика нельзя. Вы меня не услышали. Не надо пытаться ограничивать вариативность разработки.
Ну и плюс кто будет платить за создание и поддержание этих стандартов? Или ваши учёные бесплатно работать будут? И не надо писать про нулевую стоимость разработки, когда библиотеки уже созданы. Сами себя они не создадут. И поддерживать себя сами не будут.
Вы когда-нибудь сталкивались с иб в более-менее серьёзном бизнесе? Я с удовольствием посмотрю, как вы им будете объяснять, что возможность сохранить список, содержащий коммерческую тайну в файл-это оказывается стандарт такой.
Ну а если серьёзно, то что вы предлагаете-это ограничение вариативности разработки. Ну нельзя расписать до молочей все требования, которые в проектах возникают. И наука здесь абсолютно ни причем. Это никому не нужно, ни бизнесу, ни разработчикам, ни пользователям, которые это ви конечном счёте оплачивать будут.