Вы знаете у меня вроде нет проблем в осознании русского языка. Но написать «водяной» текст и что самое главное — не донести до читателя основную его суть. То про образование сообщать не нужно, ради сохранения престижа его самого.
Вот вам небольшой фидбек:
1. Делать проект на отзывах — это показывает проекта еще нет. Обычно что-то показывают (beta) и затем собирают отзывы. А так просто похоже на пиар.
2. Имя ru-egov.ru показывает, силы совсем не тратили на нормальное имя.
3. Если хотите отзывов — указывайте каналы их приема.
4. Логотип похож на eGovно. Сделали его не для посетителей (т.е. для нас), а чтобы было. Видимо статью на хабре уже начали публиковать.
>Ферштейн?
Я то все фирштейн.
Только не кто в здравом уме не будет весь поток от клиента фильтровать.
1. IP получателя = фронэнд lj
2. Порт = 80
Выбрали пакет — затем уже смотрим HOST. Полоса макс 0,05 Мбит — выдернуть пакет и разобрать хост и дальше уже акксее или дроп.
Или переслать ее на FreeBSD и слабенькая VM все выдержит.
«девочки на ресепшне на Крылатской» — Вы забили дополнить — что ресепшн по пути в Микрософт или в Интел. там не может быть средне статической секретарши. Они же только слыша заговоры ожидающих — минимум Poweruser. А на свидании может и про новые графические чипы процах рассказать.
Freebsd больше как софтверный роутер, firewall и т.д. Под сетевые нужны так сказать. Линукс по проще и по быстрее. Вот только плевать в ее сторону не стоит — такой кастомизации как у FreeBSD нет и не будет у других систем.
1. Если есть УНИКАЛЬНОЕ ЗНАЧЕНИЕ ОНО И БУДЕТ КЛЮЧОМ. тут никто суррогатного ключа и не использует.
По данной статье (Компромисс с многоколоночными ключами):
2. Говорится, что если нет Уникального значения — используйте несколько вместо суррогатного ключа.
Я же утверждаю, что если у ВАС НЕТ уникального значения в одном реквизите, то существует вероятность дубликата и следовательно лучше использовать суррогатный ключ. И они не являются «устаревшими» или компромиссом.
Поэтому их НУЖНО использовать везде, где нет УНИКАЛЬНОГО ЗНАЧЕНИЯ.
НО, есть 2-3 % случаев, когда их нужно использовать:
В этом случае — да, суррогатный ключ будет ухудшать структуру таблиц и отсутствует вероятность нарушения уникальности CLIENT_ACCOUNT и CURRENCY
поэтому для 2-3% случаев заголовок «Автоинкрементные первичные ключи (суррогатные ключи) = зло?» звучит немного «громковато»
>ИНН присваивается один раз
К сожалению в нашей стране есть люди с 2-3 ИНН и более, т.к. ИНН содержит разряд кода ИФНС и ИФНС может забыть проверить его выдачу в другой ИФНС.
Когда у нас нет уникального значения (например IP адрес), он предлагает использовать ключ из набора реквизитов (ФИО + Паспорт+ Место рождения) и данное правило будет работать в большинстве случаев.
Я же считаю, что если у нас нет одного уникального реквизита то использование составного ключа рано или поздно приведет к ошибке. Случай когда у Ваc ключ составит из 2 или более реквизитов и никогда не появится дубликат настолько редки, что в них на практике не используются суррогатные ключи.
А по данной философии использование хешей в ключах еще хуже, т.к. даже в теории не обеспечивает уникальность и это просто попытка заменить суррогатные ключи
Это не пример, а реальная БД с реальной ситуацией.
Из статьи мы видим:
У данных нет реального ключа. Очень плохая причина. Ее появление иллюстрирует как плохой дизайн базы данных в целом, таки и то, что разработчик на самом деле не понимает данных, с которыми работает.
Либо мне не везло, либо я правда не понимаю данных. Можно парочку примеров где в решении используют ключи, а можно без них? Будет отлично, если на open-source проекте.
Каждый торрент имеет так называемый info_hash, который его уникальным образом идентифицирует.
Любой хеш — это свертка текста в него, она по определению НЕ УНИКАЛЬНА.
Хеширование применяется для сравнения данных: если у двух массивов хеш-коды разные, массивы гарантированно различаются; если одинаковые — массивы, скорее всего, одинаковы. В общем случае однозначного соответствия между исходными данными и хеш-кодом нет в силу того, что количество значений хеш-функций меньше чем вариантов входного массива; существует множество массивов, дающих одинаковые хеш-коды — так называемые коллизии. Вероятность возникновения коллизий играет немаловажную роль в оценке качества хеш-функций.
Вообще время никогда не стоит использовать в качестве ключа.
Пару примеров:
Точного времени на большинстве серверов нет (http://system-administrators.info/?p=1359)
Время может «убегать», например сисадмин промахнется при переводе часов.
Время на разных серверах может расходится до 1-2 сек.
А вот теперь рассмотрим ситуацию:
У нас есть таблица Юридических Лиц. Есть 2 Уникальных Реквизита — ИНН, ОГРН. Все вот он — наш случай. Скажем НЕТ суррогату, но через пол года в базе появляется НЕРЕЗИДЕНТ, а у него данных реквизитов нет. Все наша БД запись вставит не дает, тети кричат, сисадмины в ужасе звонят разработчику, разработчик поднимает программистов и дает по шапке, разработчики в ужасе ищут статью на хабре.
Большинство случаев требует наличие первичного ключа из-за вероятности не уникальных данных, которые при ближнем рассмотрении кажутся 100% уникальными.
Вот вам небольшой фидбек:
1. Делать проект на отзывах — это показывает проекта еще нет. Обычно что-то показывают (beta) и затем собирают отзывы. А так просто похоже на пиар.
2. Имя ru-egov.ru показывает, силы совсем не тратили на нормальное имя.
3. Если хотите отзывов — указывайте каналы их приема.
4. Логотип похож на eGovно. Сделали его не для посетителей (т.е. для нас), а чтобы было. Видимо статью на хабре уже начали публиковать.
Я то все фирштейн.
Только не кто в здравом уме не будет весь поток от клиента фильтровать.
1. IP получателя = фронэнд lj
2. Порт = 80
Выбрали пакет — затем уже смотрим HOST. Полоса макс 0,05 Мбит — выдернуть пакет и разобрать хост и дальше уже акксее или дроп.
Или переслать ее на FreeBSD и слабенькая VM все выдержит.
А я сначала подумал, что из-за нее стал системник собирать.
1. Если есть УНИКАЛЬНОЕ ЗНАЧЕНИЕ ОНО И БУДЕТ КЛЮЧОМ. тут никто суррогатного ключа и не использует.
По данной статье (Компромисс с многоколоночными ключами):
2. Говорится, что если нет Уникального значения — используйте несколько вместо суррогатного ключа.
Я же утверждаю, что если у ВАС НЕТ уникального значения в одном реквизите, то существует вероятность дубликата и следовательно лучше использовать суррогатный ключ. И они не являются «устаревшими» или компромиссом.
Поэтому их НУЖНО использовать везде, где нет УНИКАЛЬНОГО ЗНАЧЕНИЯ.
НО, есть 2-3 % случаев, когда их нужно использовать:
В этом случае — да, суррогатный ключ будет ухудшать структуру таблиц и отсутствует вероятность нарушения уникальности CLIENT_ACCOUNT и CURRENCY
поэтому для 2-3% случаев заголовок «Автоинкрементные первичные ключи (суррогатные ключи) = зло?» звучит немного «громковато»
>ИНН присваивается один раз
К сожалению в нашей стране есть люди с 2-3 ИНН и более, т.к. ИНН содержит разряд кода ИФНС и ИФНС может забыть проверить его выдачу в другой ИФНС.
В статье под Вашим переводом
Компромисс с многоколоночными ключами
(ФИО + Паспорт+ Место рождения)
У данных нет реального ключа
Когда у нас нет уникального значения (например IP адрес), он предлагает использовать ключ из набора реквизитов (ФИО + Паспорт+ Место рождения) и данное правило будет работать в большинстве случаев.
Я же считаю, что если у нас нет одного уникального реквизита то использование составного ключа рано или поздно приведет к ошибке. Случай когда у Ваc ключ составит из 2 или более реквизитов и никогда не появится дубликат настолько редки, что в них на практике не используются суррогатные ключи.
А по данной философии использование хешей в ключах еще хуже, т.к. даже в теории не обеспечивает уникальность и это просто попытка заменить суррогатные ключи
Из статьи мы видим:
Либо мне не везло, либо я правда не понимаю данных. Можно парочку примеров где в решении используют ключи, а можно без них? Будет отлично, если на open-source проекте.
существует множество массивов, дающих одинаковые хеш-коды
определение вышеЭто означает, то торренты будут СОВЕРШЕННО РАЗНЫЕ.
Любой хеш — это свертка текста в него, она по определению НЕ УНИКАЛЬНА.
®
Пару примеров:
Точного времени на большинстве серверов нет (http://system-administrators.info/?p=1359)
Время может «убегать», например сисадмин промахнется при переводе часов.
Время на разных серверах может расходится до 1-2 сек.
А вот теперь рассмотрим ситуацию:
У нас есть таблица Юридических Лиц. Есть 2 Уникальных Реквизита — ИНН, ОГРН. Все вот он — наш случай. Скажем НЕТ суррогату, но через пол года в базе появляется НЕРЕЗИДЕНТ, а у него данных реквизитов нет. Все наша БД запись вставит не дает, тети кричат, сисадмины в ужасе звонят разработчику, разработчик поднимает программистов и дает по шапке, разработчики в ужасе ищут статью на хабре.
Большинство случаев требует наличие первичного ключа из-за вероятности не уникальных данных, которые при ближнем рассмотрении кажутся 100% уникальными.