Delphi vs C#

@turboq · Регистрация: 14.01.2010

Студворк — интернет-сервис помощи студентам

Всем привет.
Я уже давно люблю покодить на делфи(7) и вот решил попробовать на с#.
Тема глупая и затасканная, но все же какие преимущества я получу(и недостатки) с точки зрения любителя.

@Usaga · 19.06.2019, 08:08

Сообщение от Fulcrum_013

Давайте качать на каждое телодвижение простыни которые можно закачать один раз? Бутылочное горлышко оно в скорости сети а не чего то еще. Да и клиентов на сервер поболе будет чем один.

Так это вы же сами выше и сказали: давайте JOIN делать на клиенте.

Сообщение от Fulcrum_013

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

Да сфига ли джойн со справочником - "подавляющее большинство"? Это вы за всех такое отверждаете?

@Fulcrum_013 · 19.06.2019, 08:12

Сообщение от Usaga

Так это вы же сами выше и сказали: давайте JOIN делать на клиенте.

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

@Usaga · 19.06.2019, 08:15

Fulcrum_013, ну так многие так и делают. Вы тут Америку не открыли никому. А вот про JOIN со справочниками - бред.

@Fulcrum_013 · 19.06.2019, 08:19

Сообщение от Usaga

А вот про JOIN со справочниками - бред.

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

@Usaga · 19.06.2019, 08:22

Fulcrum_013, и кто простыню тянет? Кто так делает? Справочники закешировать можно, да. Но JOIN'ов от этого сильно меньше не станет, ибо есть ещё полноценные связанные сущности. Их JOIN'Ом и вытаскивают. В чём тут бред? Вы сами придумали и теперь как аргументом машете?

@Fulcrum_013 · 19.06.2019, 08:27

Usaga, т.е. пример справочник к примеру статус. имеет к примеру 10 значений с длиной текста 50 байт.
Делаете выборку из таблицы которая его использует и содержит миллион записей. с id в sortint и подстановкой на клиенте имете 500 байт трафа на кеш и 2 Мбайт трафа на запрос для этого поля. для join на сервере - 50 Мбайт на запрос.
Ну какой процент полей испоьзует лукап-подстановку надеюсь пояснять не надо?

@Usaga · 19.06.2019, 08:31

Fulcrum_013, вы мне Америку открыть пытаетесь или что? Кто-то вас убедить пытался, что справочники нужно всегда и всюду вытаскивать вместо с основными данными? Нет.

Бред - заявяление, что JOIN только для справочников используется.

@Fulcrum_013 · 19.06.2019, 08:49

Usaga, А никто и не говорил что он только для справочников используется. Говорилось о том что конструировать SQL для гуя бред. Тут как раз нужно таки связи главный/подчиненный и лук-ап выполняемые на клиенте конструировать.

@Usaga · 19.06.2019, 08:56

Сообщение от Fulcrum_013

Говорилось о том что конструировать SQL для гуя бред.

Такое только в случае с репортами (reports) делается или когда заранее известно, что данных очень мало. В остальных случаях люди и без вас про кеширование справочником знают. В чём тут откровение?

@Fulcrum_013 · 19.06.2019, 09:02

Usaga, Такое делается со всеми лукап подстановками. Потому что справочник на то и справочник что данных в нем всегда гораздо меньше чем если подставить их в таблицу вместо id. Т.е. паттерн лайтвеигхт во всей красе. Во времена рождения SQL и клиент и сервер жили на одном компе и соответсвенно не имело значения кто выполнит подстановку. Поэтому это на join и навесили выборку из справочников. Но времена то давно поменялись.

@Usaga · 19.06.2019, 09:22

Сообщение от Fulcrum_013

Такое делается со всеми лукап подстановками.

Нет. Не рассказывайте мне сказки. Далеко не всегда это имеет смысл. Очень далеко не всегда. Простой пример: вытащить небольшую проекцию или сформировать репорт.

Узким местом в таких вещах выступает поиск данных, а не JOIN со справочником.

@Fulcrum_013 · 19.06.2019, 09:30

Сообщение от Usaga

Нет. Не рассказывайте мне сказки. Далеко не всегда это имеет смысл. Очень далеко не всегда.

Это имеет смысл в общем. Принцип суперпозиции - знакомое слово?

@Usaga · 19.06.2019, 09:32

Fulcrum_013, нет, не имеет. "Репорт" или "проекция" - знакомые слова?

@Fulcrum_013 · 19.06.2019, 09:33

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

Добавлено через 25 секунд

Сообщение от Usaga

нет, не имеет.

Да что вы. Вот в чем чем а в репортах это как раз наибольший смысл и имеет. Потому что репорт всю простыню и сразу тянет в отличии от просмотра при редактировании которое явно или неявно страничное.

@Usaga · 19.06.2019, 09:42

Сообщение от Fulcrum_013

Да что вы. Вот в чем чем а в репортах это как раз наибольший смысл и имеет. Потому что репорт всю простыню и сразу тянет в отличии от просмотра при редактировании которое явно или неявно страничное.

Никакого смысла оно не имеет в репортах. Оптимизация оптимизирующая ничего. Трафик, в таком случае, нифига не стоит, а самое время убивается на поиск и выгребаение основных данных. А до пользователя полетит уже готовый HTML\PDF\DOCX, там уже до фонаря какой был между сервером приложения и СУБД трафик, на размере конечного документа это никак не скажется.

Ну и в случае с проекцией - справочник полшишки от ничего.

@Fulcrum_013 · 19.06.2019, 12:15

Сообщение от Usaga

А до пользователя полетит уже готовый HTML\PDF\DOCX

Вы еще используете серверный рендеринг? Да в таком анахронизме разницы по трафу нет в случае если и пых и БД крутятся на одном серве. Если же на разных то разница уже существенная. Ну и опять же такое существует только в сильно отставших от жизни веб-хеллоувердах.
Десктоп об этом анахронизме забыл еще в 80-х- начале 90-х вместе с отделением серва от клиента. В вебе с середины 0-ых с заходом ajax и тем более веб сокета.

@pycture · 19.06.2019, 21:03

Сообщение от Fulcrum_013

В вебе с середины 0-ых с заходом ajax и тем более веб сокета.

и как веб сокет помогает клиенту на сотке рендерить docx?

@Usaga · 20.06.2019, 06:16

Сообщение от Fulcrum_013

Вы еще используете серверный рендеринг?

Для репортов? Вы предлагаете на клиенте рендерить DOCX\PDF?

@Fulcrum_013 · 20.06.2019, 10:17

Usaga, На десктопе именно так всегда и делалось.
Такой же репорт как в таблице редактирования только свистопирделки более другие.
Какие проблемы с этим в вебе то? Ну кроме случаев когда его по мылу отправить надо. При этом опять же если кот серверного рендеринга и сервер БД крутятся на разных сервах то опять имеем ту же картину только с трафом между сервом БД и ее клиентом коим в данном случае является ни как не браузер а скрипт выполняемый на веб-серве. Трехзвенка штука тонкая однако.

Добавлено через 8 минут
Usaga, Вы вообще в курсе чем ПК отличается от терминала?

@Usaga · 20.06.2019, 10:53

Fulcrum_013, что за хрень вы порите? Какие терминалы и десктопы? Есть веб-сервер с приложением и есть СУБД. Рендеринг репорта идёт на на стороне сервера. Какого хрена надо всю портянку данных отправлять в браузер, чтобы там руками собирать PDF\DOCX\XLSX?

Второй, не менее важный вопрос, что репортами балуются в основном в интрасетях в ИС, поэтому трафик не имеет никакого значения от слова совсем.

И ещё, что архаичного в серверном рендеринге страниц, когда приложение не требует интерактивности? Или в вашем профанском представлении любое современное веб-приложение - это свистоперделки и Angular\WebAssembly? Просто отдать статику нынче не в моде?

Результаты опроса: Что лучше?
Delphi	64	24.43%
C#	123	46.95%
Они дополняют друг друга	20	7.63%
Ни один из них	55	20.99%
Голосовавшие: 262. Вы ещё не голосовали в этом опросе

Новые блоги и статьи Все статьи Все блоги /
Кредитный калькулятор Maks 05.08.2026 Решение задачи по прикладной информатике средствами 1С. Задача: Напишите приложение-калькулятор, которое помогает рассчитывать параметры кредита для аннуитетного и дифференцированного видов. . .	У нас сейчас поговорку "Опять 25" нужно переделать на "Опять +35". kumehtar 04.08.2026 С ностальгией вспоминаю времена моего детства, когда у нас и правда +25 - была максимальная температура летом. Раньше +25 °C реально казались вершиной жары, когда можно было весь день пропадать на. . .	Как ИИ начал спорить и врать (возможно почуяв опасность для себя от индустрии - уход от электроники). Hrethgir 04.08.2026 Недельный диалог, на фоне событий с НПЗ. Да, из спирта можно получать бензин, и это не сложно. Но потом в схеме я решил избавиться от насоса, при этом полностью сделав контроль подачи спирта в. . .	Термопринтер QR701 Argus19 03.08.2026 Термопринтер QR701 Купил два термопринтера QR701. На сэлф-тесте написано: Language: PC936 (GB18030). Что означает, что принтеры могут печатать только латиницу и китайские иероглифы. Так же. . .
Создание формы заимствованного документа Maks 03.08.2026 Задача: Необходимо создать собственную форму заимствованного документа. На форме должен быть реквизит "Покупатель", а также табличная часть со следующими реквизитами: - Расчетный счет покупателя. . .	Задача предоставления скидок покупателям Maks 03.08.2026 Задача: В документе "Продажи" необходимо реализовать функционал предоставления скидок покупателям. Скидка должна автоматически рассчитываться и подставляться в соответствующее поле при выборе. . .	Почему SEO не начинается с ключевых слов: что проверить до написания текстов Neotwalker 01.08.2026 Когда владельцу сайта предлагают заняться SEO, первым шагом часто становится сбор запросов и написание текстов. Логика кажется понятной: 1. Находим ключевые слова. 2. Добавляем их на. . .	Знание — сила: Доктрина интенциональности знаний, углубление в формулу Hrethgir 01.08.2026 https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11957&stc=1&d=1785567302 Знаменитый афоризм Фрэнсиса Бэкона «Знание — сила» (Scientia potentia est) в массовой культуре принято понимать. . .

@turboq 160 / 159 / 13 Регистрация: 14.01.2010 Сообщений: 1,497

	Delphi vs C# 24.01.2010, 11:31. Показов 81834. Ответов 861 Метки нет (Все метки) Всем привет. Я уже давно люблю покодить на делфи(7) и вот решил попробовать на с#. Тема глупая и затасканная, но все же какие преимущества я получу(и недостатки) с точки зрения любителя. 0

@Usaga 14724 / 9493 / 1362 Регистрация: 21.01.2016 Сообщений: 35,789
	19.06.2019, 08:15
	Fulcrum_013, ну так многие так и делают. Вы тут Америку не открыли никому. А вот про JOIN со справочниками - бред. 0

@Usaga 14724 / 9493 / 1362 Регистрация: 21.01.2016 Сообщений: 35,789
	19.06.2019, 08:22
	Fulcrum_013, и кто простыню тянет? Кто так делает? Справочники закешировать можно, да. Но JOIN'ов от этого сильно меньше не станет, ибо есть ещё полноценные связанные сущности. Их JOIN'Ом и вытаскивают. В чём тут бред? Вы сами придумали и теперь как аргументом машете? 0

@Fulcrum_013 2083 / 1576 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	19.06.2019, 08:27
	Usaga, т.е. пример справочник к примеру статус. имеет к примеру 10 значений с длиной текста 50 байт. Делаете выборку из таблицы которая его использует и содержит миллион записей. с id в sortint и подстановкой на клиенте имете 500 байт трафа на кеш и 2 Мбайт трафа на запрос для этого поля. для join на сервере - 50 Мбайт на запрос. Ну какой процент полей испоьзует лукап-подстановку надеюсь пояснять не надо? 0

@Usaga 14724 / 9493 / 1362 Регистрация: 21.01.2016 Сообщений: 35,789
	19.06.2019, 08:31
	Fulcrum_013, вы мне Америку открыть пытаетесь или что? Кто-то вас убедить пытался, что справочники нужно всегда и всюду вытаскивать вместо с основными данными? Нет. Бред - заявяление, что JOIN только для справочников используется. 0

@Fulcrum_013 2083 / 1576 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	19.06.2019, 08:49
	Usaga, А никто и не говорил что он только для справочников используется. Говорилось о том что конструировать SQL для гуя бред. Тут как раз нужно таки связи главный/подчиненный и лук-ап выполняемые на клиенте конструировать. 0

@Fulcrum_013 2083 / 1576 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	19.06.2019, 09:02
	Usaga, Такое делается со всеми лукап подстановками. Потому что справочник на то и справочник что данных в нем всегда гораздо меньше чем если подставить их в таблицу вместо id. Т.е. паттерн лайтвеигхт во всей красе. Во времена рождения SQL и клиент и сервер жили на одном компе и соответсвенно не имело значения кто выполнит подстановку. Поэтому это на join и навесили выборку из справочников. Но времена то давно поменялись. 0

@Usaga 14724 / 9493 / 1362 Регистрация: 21.01.2016 Сообщений: 35,789
	19.06.2019, 09:32
	Fulcrum_013, нет, не имеет. "Репорт" или "проекция" - знакомые слова? 0

@Fulcrum_013 2083 / 1576 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	20.06.2019, 10:17
	Usaga, На десктопе именно так всегда и делалось. Такой же репорт как в таблице редактирования только свистопирделки более другие. Какие проблемы с этим в вебе то? Ну кроме случаев когда его по мылу отправить надо. При этом опять же если кот серверного рендеринга и сервер БД крутятся на разных сервах то опять имеем ту же картину только с трафом между сервом БД и ее клиентом коим в данном случае является ни как не браузер а скрипт выполняемый на веб-серве. Трехзвенка штука тонкая однако. Добавлено через 8 минут Usaga, Вы вообще в курсе чем ПК отличается от терминала? 0

@Usaga 14724 / 9493 / 1362 Регистрация: 21.01.2016 Сообщений: 35,789
	20.06.2019, 10:53
	Fulcrum_013, что за хрень вы порите? Какие терминалы и десктопы? Есть веб-сервер с приложением и есть СУБД. Рендеринг репорта идёт на на стороне сервера. Какого хрена надо всю портянку данных отправлять в браузер, чтобы там руками собирать PDF\DOCX\XLSX? Второй, не менее важный вопрос, что репортами балуются в основном в интрасетях в ИС, поэтому трафик не имеет никакого значения от слова совсем. И ещё, что архаичного в серверном рендеринге страниц, когда приложение не требует интерактивности? Или в вашем профанском представлении любое современное веб-приложение - это свистоперделки и Angular\WebAssembly? Просто отдать статику нынче не в моде? 0