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. Вы ещё не голосовали в этом опросе

Новые блоги и статьи Все статьи Все блоги /
[golang] Двоичная куча, min-heap alhaos 20.05.2026 Двоичная куча Двоичная куча — структура данных, которая всегда держит самый важный элемент наготове. Представьте очередь к хилеру в игре, и очередь из игроков в приоритете те у кого меньше. . .	[golang] Breadth-First Search alhaos 19.05.2026 BFS (Breadth-First Search) — это базовый алгоритм обхода графа в ширину, который поуровнево исследует все связанные вершины. Он начинает с выбранной точки и проверяет всех соседей, прежде чем. . .	[golang] Алгоритм «Хак Госпера» alhaos 17.05.2026 Алгоритм «Хак Госпера» Хак Госпера (Gosper's Hack) — алгоритм нахождения следующего по величине числа с тем же количеством установленных бит. Придуман Биллом Госпером в 1970-х, опубликован в. . .	Рисование бинарного древа до 6-го колена на js, svg. russiannick 17.05.2026 <svg width="335" height="240" viewBox="0 0 335 240" fill="#e5e1bb"> <style> <!]> </ style> <g id="bush"> </ g> </ svg> function fn(){ let rost;/ / высота древа let xx=165,yy=210,w=256;
FSharp: interface of module DevAlt 16.05.2026 Интерфейс модуля F# позволяет управлять доступностью членов, содержащихся в реализации модуля. По-умолчанию все члены модуля доступны: module Foo let x = 10 let boo () = printfn "boo" . . .	Хитросплетение родственных связей пантеона греческих богов. russiannick 14.05.2026 Однооконник, позволяющий узреть и изучить отдельных героев древней Греции. <!DOCTYPE html> <html lang="ru"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible". . .	[golang] Угол между стрелками часов alhaos 12.05.2026 По заданным значениям часа и минуты необходимо определить значение меньшего угла между стрелками аналогового циферблата часов. import "math" func angleClock(hour int, minutes int) float64 { . . .	Debian 13: Установка Lazarus QT5 ВитГо 09.05.2026 Эта инструкция моя компиляция инструкций volvo https:/ / www. cyberforum. ru/ blogs/ 203668/ 10753. html и его же старой инструкции по установке Lazarus с gtk2. . .

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

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

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

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

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

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

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

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

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

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

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