1. Все запросы обрабатывает центральная служба.
2. Все запросы службы к БД выполняются в одном потоке.
3. Тогда я перед вставкой клерка в БД считаю количество уже существующих клерков и не даю вставлять если их больше чем нужно.
4. Т.к. запросы сериализованы – первый пройдет, остальные обломятся.
Мне приходилось видеть людей, которые загружали данные всей таблицы запросом select * from tbl, чтобы подсчитать количество строк или сумму значений по какому-то полю.
Юнцов хватает в любой сфере деятельности человека. Но здесь то речь идет о явно опытном специалисте. И он пишет правильные вещи, только на мой взгляд в не правильном месте. На сколько я понимаю текущие тенденции, все идет к тому, чтобы использовать БД в качестве массового хранилища данных с минимальным количеством логики внутри (обычно оставляют только минимальные constraint'ы) – это проще, лучше обслуживается, легче масштабируется.
юнит-тестирование логики не сильно отличается от других языков.
Я слабо верю в то, что тесты для моего кода на С# будут столь же затратны по времени как и тесты для SQL написаннные на SQL.
Я бы сказал что это небольшая база, в SAP к примеру одних только таблиц десятки тысяч.
Я писал о том, что в базе было много кода, а не много таблиц. Количеством таблиц меня не удивить. Меня пугает, когда эти таблицы живут своей жизнью, связаны кучей триггеров и используют сотни хранимых процедур для отработки какой-то логики внутри БД.
А я думал, что люди, пишущие бизнес логику в БД уже не существуют. Как вы с этим потом живете? Миграции, отсутствие нормальных средств тестирования. Я как-то видел базу в которой десятки тысяч строк кода. Это был ад.
Поверх L2 есть еще какие-то каналы? Окей, я попробовал в поисковике поискать словосочетания «Ethernet channel» и «UDP channel» и сравнить количество результатов, Вы тоже попробуйте.
Что вы хотели этим сказать? Что их нет потому что мало ссылок на UDP против Ethernet? Поищите IP channel.
На мой взгляд Ethernet это достаточно конкретная вещь. Это всё равно что транспорт и автомобиль. Транспорт = Internet канал. Автомобиль = Ethernet. Поэтому прочитав заголовок "секреты тестирования ethernet" я ожидал увидеть как будут грузить свитчи, убивать сетевые карточки и выжимать все из последних 100 метров кабеля. Расскажут как потестить качество задели розетки и патч панелей. На деле же нам рассказали, что софт — фуфло. Покупайте наши тестеры или берите в аренду.
Ethernet определяют проводные соединения и электрические сигналы на физическом уровне, формат кадров и протоколы управления доступом к среде — на канальном уровне модели OSI
А Интернет канал это, по большей части, все что выше канального уровня модели OSI. Начиная с IP протокола и далее.
Это как озаглавить статью "Тестируем качество нержавеющих вилок" и плавно перейти к тестированию добросовестности производителей еды. Понимаете разницу?
А еще дама то ли путает, то ли не понимает разницы между Ethernet и интернет каналом. Сначала собирается тестировать Ethernet, потом как то плавно это превращается в тестирование качества телематических услуг.
Мы давно отошли от модели один запрос – одно соединение. И везде используем открытые / пул соединений. А что там с пингами между вашими узлами? Я всё равно не могу понять как 1.5 миллисекунды требуемые для передачи 150 КБ по сети на 1гбит могут вырасти до 200 мс на 10гбит сети. Даже с учетом всех этих прослоек. А уж про 950 мс и подавно понять не могу.
И всё равно это очень медленно. Расчет для гигабитной сети дает производительность в 6-15 миллисекунд с большим запасом. Я не знаю что там у вас за код, но у меня сервисы общающиеся между собой передают такие данные за единицы миллисекунд с binary сериализацией. Json медленнее раза в 2-3 не больше. Ох уж эти современные браузерные технологии.
Легко. Я могу подключится на один из серверов, открыть там браузер, в нем — stack overflow, после чего отключится и не появляться там месяцок. Видать не один я такой.
1. Все запросы обрабатывает центральная служба.
2. Все запросы службы к БД выполняются в одном потоке.
3. Тогда я перед вставкой клерка в БД считаю количество уже существующих клерков и не даю вставлять если их больше чем нужно.
4. Т.к. запросы сериализованы – первый пройдет, остальные обломятся.
Юнцов хватает в любой сфере деятельности человека. Но здесь то речь идет о явно опытном специалисте. И он пишет правильные вещи, только на мой взгляд в не правильном месте. На сколько я понимаю текущие тенденции, все идет к тому, чтобы использовать БД в качестве массового хранилища данных с минимальным количеством логики внутри (обычно оставляют только минимальные constraint'ы) – это проще, лучше обслуживается, легче масштабируется.
Я слабо верю в то, что тесты для моего кода на С# будут столь же затратны по времени как и тесты для SQL написаннные на SQL.
Я писал о том, что в базе было много кода, а не много таблиц. Количеством таблиц меня не удивить. Меня пугает, когда эти таблицы живут своей жизнью, связаны кучей триггеров и используют сотни хранимых процедур для отработки какой-то логики внутри БД.
Что вы хотели этим сказать? Что их нет потому что мало ссылок на UDP против Ethernet? Поищите IP channel.
На мой взгляд Ethernet это достаточно конкретная вещь. Это всё равно что транспорт и автомобиль. Транспорт = Internet канал. Автомобиль = Ethernet. Поэтому прочитав заголовок "секреты тестирования ethernet" я ожидал увидеть как будут грузить свитчи, убивать сетевые карточки и выжимать все из последних 100 метров кабеля. Расскажут как потестить качество задели розетки и патч панелей. На деле же нам рассказали, что софт — фуфло. Покупайте наши тестеры или берите в аренду.
А Интернет канал это, по большей части, все что выше канального уровня модели OSI. Начиная с IP протокола и далее.
А может все-таки "вы"?