Глобальная Авантюра  
ФОРУМ
главное меню
  1. >
  2. Блог >
  3. TAU >
  4. Что нужно знать программисту

Что нужно знать программисту

 
15 сентября 2019 00:33:22 / 26.09.2019 21:59:45   154 51 0.00 / 0 +0.95 / 81
 
TAU
  TAU
Цитата
Замечательно при этом, что сортировки всплывающим пузырьком нет. Это как у радистов не будет преобразования Фурье

Нет - и не надо. Этот способ сортировки - зло. Нечего время тратить, чтобы узнать, как не стоит делать. Лучше сразу - как стоит.

+ 0.00 / 0

КОММЕНТАРИИ (51)

  в виде   дерева списка
 
  adolfus
 
   
adolfus  
 
Нет - и не надо. Этот способ сортировки - зло. Нечего время тратить, чтобы узнать, как не стоит делать. Лучше сразу - как стоит.
А лучше всего вообще ни на что время не тратить, а сразу юзать STL. Или еще лучше, ничего не программировать, просто использовать готовое.
Вы когда нибудь задумывались, что вроде как постоянно растет производительность железа, объем памяти, а приложения становятся все более тормозными? А потому, что нечего время тратить на изучение структур данных и алгоритмов, языков низкого уровня, а сразу в котлин, скалу и пайтон.
Отредактировано: adolfus - 15 сентября 2019 04:02:17
+ 0.04 / 3
 
 
   
Explorer-2000   Канада
 
А лучше всего вообще ни на что время не тратить, а сразу юзать STL. Или еще лучше, ничего не программировать, просто использовать готовое.
Вы когда нибудь задумывались, что вроде как постоянно растет производительность железа, объем памяти, а приложения становятся все более тормозными? А потому, что нечего время тратить на изучение структур данных и алгоритмов, языков низкого уровня, а сразу в котлин, скалу и пайтон.
В каком то смысле это верно, 4 недельных курсов MS закрывают весь девелопментПодмигивающий и можно поднимать хорошие бапкиПодмигивающий, не забываем что абсолютное большинство современных програмистов никогда и не сталкиваются ни с какими структурами данных.
+ 0.00 / 0
   
 
  adolfus
 
   
adolfus  
 
В каком то смысле это верно, 4 недельных курсов MS закрывают весь девелопментПодмигивающий и можно поднимать хорошие бапкиПодмигивающий, не забываем что абсолютное большинство современных програмистов никогда и не сталкиваются ни с какими структурами данных.
Интересно, а какова польза нам от этого "большинства современных программистов" с 4-х недельными курсами MS? Их как-то можно использовать для решения внутрироссийских айти-проблем?
Кстати, а что такое "курсы MS"?
+ 0.00 / 0
     
 
  Oleg K.
 
   
Oleg K.   Россия
Москва
34 года
 
Интересно, а какова польза нам от этого "большинства современных программистов" с 4-х недельными курсами MS? Их как-то можно использовать для решения внутрироссийских айти-проблем?
Кстати, а что такое "курсы MS"?
Я не знаю, что там за курсы от MS, но зато знаю, что нынче на Украине полным полно "бывших домохозяек и грузчиков, которые вошлиВАйТитм" - этот спецтермин означает человека без хороших знаний логики, комбинаторики и дискретной математики, который научился выполнять определенные действия на компьютере и после этого все его называют "программистом": 1) он сам себя так называет, 2) окружающие его так называют, 3) работодатель его под видом программиста продаёт в качестве аутсорс-ресурса (в том числе и в Россию).
Но программистом этот человек не является, и сложные задачи он никогда не решит (это как раз тот случай, когда для решения сложной задачи будет принято очевидное простое и неправильное решение). Пользы от этого "большинства современных программистов" ровно столько же, сколько от "большинства продавцов-консультатов" в какой-нибудь евросети.
+ 0.11 / 5
       
 
  mark.76
 
   
mark.76   Россия
Малая Вишера
 
Я не знаю, что там за курсы от MS, но зато знаю, что нынче на Украине полным полно "бывших домохозяек и грузчиков, которые вошлиВАйТитм" - этот спецтермин означает человека без хороших знаний логики, комбинаторики и дискретной математики, который научился выполнять определенные действия на компьютере и после этого все его называют "программистом": 1) он сам себя так называет, 2) окружающие его так называют, 3) работодатель его под видом программиста продаёт в качестве аутсорс-ресурса (в том числе и в Россию).
Но программистом этот человек не является, и сложные задачи он никогда не решит (это как раз тот случай, когда для решения сложной задачи будет принято очевидное простое и неправильное решение). Пользы от этого "большинства современных программистов" ровно столько же, сколько от "большинства продавцов-консультатов" в какой-нибудь евросети.
А когда программисты отличались от машинисток? Человек способный поставить задачу, должен как минимум быть электроником, а этому на курсах и по специальности программирования не учат - не знаешь как работает железо, значит быдлокодер. Так это было всегда.
"Мне плевать на вас ублюдки.
Я анархо-аморал." (С)
-0.14 / 5
         
 
   
Explorer-2000   Канада
 
А когда программисты отличались от машинисток? Человек способный поставить задачу, должен как минимум быть электроником, а этому на курсах и по специальности программирования не учат - не знаешь как работает железо, значит быдлокодер. Так это было всегда.
Ну вот есть например Сбербанк-онлайн, ну и какие знания в электронике нужны чтобы поставить такую задачуНепонимающий
+ 0.00 / 0
         
 
  Oleg K.
 
   
Oleg K.   Россия
Москва
34 года
 
А когда программисты отличались от машинисток? Человек способный поставить задачу, должен как минимум быть электроником, а этому на курсах и по специальности программирования не учат - не знаешь как работает железо, значит быдлокодер. Так это было всегда.
Вы извините, но я ничего не понял. Может раскроете мысль чуть более подробно?
На всякий случай - все нормальные программисты и сейчас, и раньше, и очень-очень давно всегда знали хотя бы в общих чертах, как работают нижележащие уровни (и это может быть совсем не железо). Знать полностью все слои сейчас невозможно.
Вот по поводу "железа" - вы на верилоге или vhdl сможете с ходу обычный сдвиговый регистр написать? Лично я не смогу, хотя и понимаю примерно что там к чему.
Про уровни транзисторов в кристалле процессоров или протоколы взаимодействия с оперативной памятью я молчу. Так до какого уровня должны программисты знать всё, чтобы не быть быдлокодерами?
+ 0.06 / 2
           
 
   
Быдлокодер  
 
Вы извините, но я ничего не понял. Может раскроете мысль чуть более подробно?
На всякий случай - все нормальные программисты и сейчас, и раньше, и очень-очень давно всегда знали хотя бы в общих чертах, как работают нижележащие уровни (и это может быть совсем не железо). Знать полностью все слои сейчас невозможно.
Вот по поводу "железа" - вы на верилоге или vhdl сможете с ходу обычный сдвиговый регистр написать? Лично я не смогу, хотя и понимаю примерно что там к чему.
Про уровни транзисторов в кристалле процессоров или протоколы взаимодействия с оперативной памятью я молчу. Так до какого уровня должны программисты знать всё, чтобы не быть быдлокодерами?
Вот я, чтобы стать программистом, старательно по каплям выдавливал из себя мышление физика. Потому что сложность высокая и уровней абстракции сильно много, и практически никогда не нужно знать самый низ. Ну или забыть. Мыслишь уровнями, в голове 3-4 уровня максимум. Веришь, что уровни ниже работают как им положено. Если они не работают - я смещаюсь на уровень вниз и вожусь уже с ним, и тогда из кэша вытесняется что-то из уровней выше.
Уж веб-программист точно никогда не доберется до топологии СБИС. Или там разработчик ядра СУБД - ну зачем ему что-то ниже языка С? Я теперь с контроллерами вожусь - и практически никогда даже ассемблер целевой железки не нужен - ну если это не глючной 8051 с глючным же кейлом - но оно, слава Богу, подохло - и туда ему и дорога.
Кораблик космический
Летел и насвистывал
Дырочкой в правом боку.
+ 0.00 / 0
             
 
   
Поверонов  
 
Вот я, чтобы стать программистом, старательно по каплям выдавливал из себя мышление физика. Потому что сложность высокая и уровней абстракции сильно много, и практически никогда не нужно знать самый низ. Ну или забыть. Мыслишь уровнями, в голове 3-4 уровня максимум. Веришь, что уровни ниже работают как им положено. Если они не работают - я смещаюсь на уровень вниз и вожусь уже с ним, и тогда из кэша вытесняется что-то из уровней выше.
Уж веб-программист точно никогда не доберется до топологии СБИС. Или там разработчик ядра СУБД - ну зачем ему что-то ниже языка С? Я теперь с контроллерами вожусь - и практически никогда даже ассемблер целевой железки не нужен - ну если это не глючной 8051 с глючным же кейлом - но оно, слава Богу, подохло - и туда ему и дорога.
ядро СУБД тесно работает со всеми кэшами ввода-вывода ОС и нередко ( есть опции ) берет их под свое управление
+ 0.00 / 0
               
 
  Senya
 
   
Senya   Россия
50 лет
 
ядро СУБД тесно работает со всеми кэшами ввода-вывода ОС и нередко ( есть опции ) берет их под свое управление
Функции операционной системы выше по уровню, чем язык на котором они написаны.
Ниже по уровню - например реализация Skein на С, учитывающая архитектуру процессора и позволяющая задействовать все три вычислительных блока за такт.
Отредактировано: Senya - 17 сентября 2019 10:00:01
"Иван Грозный помещает на рабочий стол полученный от хана ярлык."(с) Не моё.
+ 0.04 / 4
                 
 
   
Быдлокодер  
 
Функции операционной системы выше по уровню, чем язык на котором они написаны.
Ниже по уровню - например реализация Skein на С, учитывающая архитектуру процессора и позволяющая задействовать все три вычислительных блока за такт.
А, ну да, а ещё всякие Hackers delight и Duff device. Это я люблю.
Кстати, сколько не пробовал - ничего толком duff device не давало.
Premature optimization is the root of all evil.
Кораблик космический
Летел и насвистывал
Дырочкой в правом боку.
+ 0.03 / 1
                   
 
  Senya
 
   
Senya   Россия
50 лет
 
Premature optimization is the root of all evil.
Вот честно - изначально учил делать низкоуровневую оптимизацию. Но когда компы с трёшек заменили на 486, и оптимизированные и неоптимизированные программы стали давать практически одинаковое время исполнения - завязал с этим грязным делом Веселый
Но с другой стороны другого способа программно обеспечить под 600 мегабайт потокового шифрования в секунду и скажем прозрачно шифровать SSD на сегодня нет.
"Иван Грозный помещает на рабочий стол полученный от хана ярлык."(с) Не моё.
+ 0.05 / 5
                     
 
   
Быдлокодер  
 
Вот честно - изначально учил делать низкоуровневую оптимизацию. Но когда компы с трёшек заменили на 486, и оптимизированные и неоптимизированные программы стали давать практически одинаковое время исполнения - завязал с этим грязным делом Веселый
Но с другой стороны другого способа программно обеспечить под 600 мегабайт потокового шифрования в секунду и скажем прозрачно шифровать SSD на сегодня нет.
Ну иногда приходится. Нормальный разработчик это чувствует и сразу делает, как минимум, приемлемую версию. Ну или хотя бы обозначит проблему сразу.
Приведенную выше цитату про premature optimization мне выдал представитель заказчика, у которого подсистема хранения и, в частности, деревья были реализованы мм... странно. И заведомо неэффективно. Но типа - пока так сайдет. Ну ок: ты заказчик - я дурак, мне за часы платят...
Кораблик космический
Летел и насвистывал
Дырочкой в правом боку.
+ 0.03 / 1
                       
 
  VictorS
 
   
VictorS   Россия
Moscow
61 год
 
Ну иногда приходится. Нормальный разработчик это чувствует и сразу делает, как минимум, приемлемую версию. Ну или хотя бы обозначит проблему сразу.
Приведенную выше цитату про premature optimization мне выдал представитель заказчика, у которого подсистема хранения и, в частности, деревья были реализованы мм... странно. И заведомо неэффективно. Но типа - пока так сайдет. Ну ок: ты заказчик - я дурак, мне за часы платят...
Ответ не на Ваше сообщение. Просто по теме. Сегодня нас программистов поздравляли с прошедшим праздником админы. Они по пятницам не всегда на месте. Я давно уже не пишу. Все, что прочитал на этой странице, все бла.бла. В 90 годы было время индивидуальных программистов. Среди моих разработок много интересного, которые были внедрены. Я вовремя понял, что время одиночек прошло. Ушел в другую область. Грустный
А может это главное для программиста, вовремя остановиться, и сменить вид деятельности. Уверен, что, программисты это очень умные люди которым не нужны чужие советы.
Отредактировано: VictorS - 17 сентября 2019 15:15:01
+ 0.00 / 0
                     
 
  bb1788
 
   
bb1788  
 
Скрытый текст

Но с другой стороны другого способа программно обеспечить под 600 мегабайт потокового шифрования в секунду и скажем прозрачно шифровать SSD на сегодня нет.

Нуу, под эото делоо народ (есть такой) не только свои драйвера пишет, а некоторые (сильно упоротые) свою операционку со своим ядрышком под своё же разработанное железо со своими прошивочками.
Но это да - если совсем невтерпёж (дане, не замуж, а к гигабайтам потоков, дане, не для передачи - для обработки, и записи, и чтения, ну, а потом уж предача).
+ 0.03 / 1
                     
 
  adolfus
 
   
adolfus  
 
Вот честно - изначально учил делать низкоуровневую оптимизацию. Но когда компы с трёшек заменили на 486, и оптимизированные и неоптимизированные программы стали давать практически одинаковое время исполнения - завязал с этим грязным делом Веселый
Но с другой стороны другого способа программно обеспечить под 600 мегабайт потокового шифрования в секунду и скажем прозрачно шифровать SSD на сегодня нет.
Встроенный SATA rev.3? Используя процессор нет и никогда не будет. SATA данные берет из ОЗУ. Считаем – кто-то асинхронно, но со скоростью 600 Мбайт/с кладет плайнтекст в ОЗУ (1), крипроалгоритм читает плайнтекст (2), его курочит на процессоре и выкладывает шифртекст в ОЗУ (3), потом интерфейс забирает этот шифртекст из ОЗУ (4) и отправляет в диск. Это если мимо файловой и даже мимо операционной системы. Рядом, соответственно, трудится операционка и куча приложений, котороым также требуется ОЗУ. Интерфейс памяти в резульате будет полностью перегружен – 25 Гбит/с вынь да положь.
Но выход есть – шифрующий спецконтроллер SATA/eSATA, воткнутый в длинный PCI Express отлично все успевает и грузит память только на 6 Гбит/с.
Отредактировано: adolfus - 16 сентября 2019 23:00:38
+ 0.03 / 1
                   
 
  adolfus
 
   
adolfus  
 
Premature optimization is the root of all evil.
Это точно. Гораздо больше можно достичь, умело организуя данные и используя правильные алгоритмы.
+ 0.00 / 0
               
 
   
Быдлокодер  
 
ядро СУБД тесно работает со всеми кэшами ввода-вывода ОС и нередко ( есть опции ) берет их под свое управление
Ещё раз: при чем тут электроника.
Я писал: не надо ниже языка С. Ядро ОС - это выше.
Ну плюс ликбез про то, что у диска головки ездЮЮт. Что-то ещё из железа?
А вот алгоритмов в ядре СУБД - вот этого там овердофига...
Чисто алгоритмы. На С. Много. Ну на С++, может.
Кораблик космический
Летел и насвистывал
Дырочкой в правом боку.
+ 0.00 / 0
                 
 
  adolfus
 
   
adolfus  
 
А вот алгоритмов в ядре СУБД - вот этого там овердофига...
Чисто алгоритмы. На С. Много. Ну на С++, может.
Это вряд ли. Поженить ООП и SQL пока еще никому не удалось – там противоречия на уровне парадигмы. Поэтому нет никакой необходимости в кишках и недрах СУБД писать что-то на С++ без классов, если тут же рядом есть С, на котором можно написать вообще все.
А для гиков и членов секты свидетелей ООП есть привязки к некоторой части интерфейса к СУБД и все счастливы.
+ 0.00 / 0
                   
 
  DarkRaider
 
   
DarkRaider   Россия
Москва
38 лет
 
Это вряд ли. Поженить ООП и SQL пока еще никому не удалось – там противоречия на уровне парадигмы.
Mon cher ami, Вы, как всегда, слишком категоричны.
Во первых, современные СУБД вполне себе официально называются "объектно-реляционными базами данных" и таки имеют достаточно признаков и возможностей на эту тему.
Для примера PostgresSQL вот тут даже в начало статьи гордо вынесли.. MS SQL, Oracle тоже дозволяют многое. И это я говорю лишь о возможностях самих СУБД. Во вторых, если копнуть вопрос НАПИСАНИЯ субд, то без ООП обойтись не получится,если Вы не извращенец и если пишите УНИВЕРСАЛЬНУЮ СУБД (принеси и сохрани то - не знаю что).

Цитата
Поэтому нет никакой необходимости в кишках и недрах СУБД писать что-то на С++ без классов, если тут же рядом есть С, на котором можно написать вообще все.
А для гиков и членов секты свидетелей ООП есть привязки к некоторой части интерфейса к СУБД и все счастливы.

Что то я опять, Вас, не пойму, в чём суть очередного дефиле?
С++ появился путём добавления ООП механизмов в С, откуда взялась идея писать на C++ без классов?
-0.00 / 2
                     
 
  adolfus
 
   
adolfus  
 
Mon cher ami, Вы, как всегда, слишком категоричны.
Во первых, современные СУБД вполне себе официально называются "объектно-реляционными базами данных" и таки имеют достаточно признаков и возможностей на эту тему.
"Объектно-реляционный" – это всего-лишь составное слово, ничего не обозначающее кроме модного набора звуков. Что, например, может означать слово "плотно-разреженный"? На самом деле либо объектная модель данных, либо реляционная. Отобразить таблицы реляционной модели в структуры объектной пока никак не получается – проблема есть такая "object-relation mapping". Вот когда ее математики решат, возможно тогда словосочетание "объектно-реляционный" наполнится реальным смыслом, а так пока всего-лишь попытки забить колышки на участке, который кажется золотоносным.
+ 0.02 / 1
                       
 
  DarkRaider
 
   
DarkRaider   Россия
Москва
38 лет
 
На самом деле либо объектная модель данных, либо реляционная. Отобразить таблицы реляционной модели в структуры объектной пока никак не получается – проблема есть такая "object-relation mapping". Вот когда ее математики решат, возможно тогда словосочетание "объектно-реляционный" наполнится реальным смыслом, а так пока всего-лишь попытки забить колышки на участке, который кажется золотоносным.

"Всё дело, в волшебных пузырьках!", как нас заверяла реклама одной шоколадки.
"Реляционная" СУБД - та, где имеется чёткое соответствие отношений хранимых объектов (идентификатор или комбинация признаков его составляющая). Такая СУБД вполне спокойно хранит любые объекты - в том числе и бинарные, в том числе и классы (например тот же XML имеющий свои методы). Современные СУБД расширяются внешними и внутренними процедурами, представляющими тоже объекты, в том числе и бинарные. Есть типизация, абстракция, преобразование типов - достаточно признаков чтобы назвать объектно-реляционной СУБД?

Почитаем вики объектно ориентированная база данных.

Сравним признаки?

Поддержка сложных объектов. В системе должна быть предусмотрена возможность создания составных объектов за счёт применения конструкторов составных объектов. Необходимо, чтобы конструкторы объектов были ортогональны, то есть любой конструктор можно было применять к любому объекту.
Поддержка сложных объектов есть. Оговорка про конструкторы - не к месту. СУБД хранит и предоставляет доступ к данным, это не хост исполняемых процессов. Даже если там сохранены объекты как есть - они в любом случае сериализованы. И в любом случае их нельзя хранить "полностью в готовом виде" - так как при извлечении и размещении в памяти - должны быть заданы адреса в оперативке - это и есть "создание объекта определённого класса" и это опять таки вопрос исполняемого кода, а не хранения данных.

Поддержка индивидуальности объектов. Все объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов.
Это скорее свойство реляционных.

Поддержка инкапсуляции. Корректная инкапсуляция достигается за счёт того, что программисты обладают правом доступа только к спецификации интерфейса методов, а данные и реализация методов скрыты внутри объектов.
Чем плоха модель безопасности обычной СУБД? Монопениссуально.


Поддержка типов и классов. Требуется, чтобы в ООБД поддерживалась хотя бы одна концепция различия между типами и классами. (Термин «тип» более соответствует понятию абстрактного типа данных. В языках программирования переменная объявляется с указанием её типа. Компилятор может использовать эту информацию для проверки выполняемых с переменной операций на совместимость с её типом, что позволяет гарантировать корректность программного обеспечения. С другой стороны класс является неким шаблоном для создания объектов и предоставляет методы, которые могут применяться к этим объектам. Таким образом, понятие «класс» в большей степени относится ко времени исполнения, чем ко времени компиляции.)
Смотрим пункт №1. Только в разрезе времени выполнения, а не в разрезе управления данными.

Поддержка наследования типов и классов от их предков. Подтип, или подкласс, должен наследовать атрибуты и методы от его супертипа, или суперкласса, соответственно.
Перегрузка в сочетании с полным связыванием. Методы должны применяться к объектам разных типов. Реализация метода должна зависеть от типа объектов, к которым данный метод применяется. Для обеспечения этой функциональности связывание имен методов в системе не должно выполняться до времени выполнения программы.

Этого нет и врядли когда то будет в обычных СУБД. Нахуа?

Вычислительная полнота. Язык манипулирования данными должен быть языком программирования общего назначения.
Ну вот обычная библиотека - это ведь СУБД? В ней хранят книги - это объекты? Составные? Сложные? И метод у каждой книги есть свой (Book.Дряхлеть) ну это тот что присущ объекту самому, без посторонних вмешательств. Какая у библиотеки вычислительная мощность? 3 калькулятора, если по этажам собрать?

Набор типов данных должен быть расширяемым. Пользователь должен иметь средства создания новых типов данных на основе набора предопределённых системных типов. Более того, между способами использования системных и пользовательских типов данных не должно быть никаких различий.
Смотрим пункт (1).

Итого на мой взгляд: вся вот эта муть написанная про "чистые" ООСУБД = сова натянутая на глобус. По тому, что смешаны понятия управления данными и программных действий над ними производимых. До тех пор пока мы не доживём до появления саморегулируемых цифровых данных. Все СУБД которые занимаются именно ХРАНЕНИЕМ и УПРАВЛЕНИЕМ доступом к данным - можно смело отнести в объектно-реляционным, в том понимании, что они способны хранить сложно-составные данные (сериализованные объекты) и хранимые отношения между ними (те связи которые присущи объектам вне контекста их последующего исполнения).
Отредактировано: DarkRaider - 18 сентября 2019 18:45:01
+ 0.05 / 2
                         
 
  adolfus
 
   
adolfus  
 
"Всё дело, в волшебных пузырьках!", как нас заверяла реклама одной шоколадки.
"Реляционная" СУБД - та, где имеется чёткое соответствие отношений хранимых объектов (идентификатор или комбинация признаков его составляющая). Такая СУБД вполне спокойно хранит любые объекты - в том числе и бинарные, в том числе и классы (например тот же XML имеющий свои методы). Современные СУБД расширяются внешними и внутренними процедурами, представляющими тоже объекты, в том числе и бинарные. Есть типизация, абстракция, преобразование типов - достаточно признаков чтобы назвать объектно-реляционной СУБД?

Почитаем вики объектно ориентированная база данных.

Сравним признаки?

Скрытый текст
Основная особенность всех СУБД, в том числе и реляционных, состоит в том, что никто не знает, какие действия и кем будут предприниматься над данными. Поэтому с ними работают с помощью декларативного SQL, а не лезут к данным напрямую – что и как там крутить решает СУБД. Иногда используют ISAM, но опять же не к данным, а их статичным представлениям, рискуя напороться на конкурентные процессы, изменяющие структуру и связи.
В БД хранятся сущности и отношения между ними. И те и другие представляют непрерывно обновляемые динамические структуры данных. Представить их в виде объектов (в смысле ООП) невозможно – сущности и отношения очень динамичны, в то время как объекты – просто экземпляры класса (типа). Объекты могут представлять лишь моментальный слепок простейших статичных состояний БД, в то время как в процессе работы меняются не только сущности и отношения, которыми управляет пользователь, но и те сущности и отношения, которыми управляет СУБД. Причем последних гораздо больше – каждый запрос генерирует их огромное количество.
Что касается xml, то это очень убогий способ представления отношений, поскольку реальные отношения представляются графами, а не деревьями.
+ 0.02 / 1
                           
 
   
Поверонов  
 
Основная особенность всех СУБД, в том числе и реляционных, состоит в том, что никто не знает, какие действия и кем будут предприниматься над данными. Поэтому с ними работают с помощью декларативного SQL, а не лезут к данным напрямую – что и как там крутить решает СУБД. Иногда используют ISAM, но опять же не к данным, а их статичным представлениям, рискуя напороться на конкурентные процессы, изменяющие структуру и связи.
В БД хранятся сущности и отношения между ними. И те и другие представляют непрерывно обновляемые динамические структуры данных. Представить их в виде объектов (в смысле ООП) невозможно – сущности и отношения очень динамичны, в то время как объекты – просто экземпляры класса (типа). Объекты могут представлять лишь моментальный слепок простейших статичных состояний БД, в то время как в процессе работы меняются не только сущности и отношения, которыми управляет пользователь, но и те сущности и отношения, которыми управляет СУБД. Причем последних гораздо больше – каждый запрос генерирует их огромное количество.
Что касается xml, то это очень убогий способ представления отношений, поскольку реальные отношения представляются графами, а не деревьями.
В объектно-реляционных СУБД "объектами" ( а точнее классами ) являются не данные, а "процедуры" оформленные в виде классов. При этом таблица есть лишь способ хранения атрибутов экземпляров класса ( по принципу запись - экземпляр класса ). Все отношения между классами поддерживаются через функции классов, то есть вынесены в процедуры. Собственно СУБД при этом используется лишь для хранения экземпляров классов - по сути это NoSQL, так как всё делается в процедурах без всяких оптимизированных планов исполнения (execution plan )
+ 0.02 / 2
                             
 
  adolfus
 
   
adolfus  
 
В объектно-реляционных СУБД "объектами" ( а точнее классами ) являются не данные, а "процедуры" оформленные в виде классов. При этом таблица есть лишь способ хранения атрибутов экземпляров класса ( по принципу запись - экземпляр класса ). Все отношения между классами поддерживаются через функции классов, то есть вынесены в процедуры. Собственно СУБД при этом используется лишь для хранения экземпляров классов - по сути это NoSQL, так как всё делается в процедурах без всяких оптимизированных планов исполнения (execution plan )
Невозможно отношения вынести в процедуры, поскольку процедуры – это фундаментально статичные сущности, а отношения нет.
Хотя, да на здоровье. Хоть горшком обзови...
+ 0.00 / 0
                               
 
  DarkRaider
 
   
DarkRaider   Россия
Москва
38 лет
 
Невозможно отношения вынести в процедуры, поскольку процедуры – это фундаментально статичные сущности, а отношения нет.
Хотя, да на здоровье. Хоть горшком обзови...
Например MS SQL (вполне себе классическая реляционная СУБД), "на пальцах":
Параметр1=Таблица1.столбец1
Параметр2=Таблица1.столбец2
Таблица1.столбец3=Текст(Скуль Update над параметром 1 и 2(обновить Таблицу2.Строку3=Параметр1+Параметр2)
Испольнить
Параметр1=Таблица1.столбец1*3
Таблица1.столбец3=Текст(Скуль Update над параметром 1 и 2(обновить Таблицу2.Строку4=Параметр1-Параметр2+2)
Испольнить

Отношения между таблицей 1 и 2 выражены процедурой?
Сущности очень фундаментально статичны?
Данные изменяются сами по себе?
Вы, любезный, помнится несколько постов назад вообще уверяли:

Цитата
... В БД хранятся сущности и отношения между ними. И те и другие представляют непрерывно обновляемые динамические структуры данных...

Вы уж определитесь в какую сторону грести, пожалуйста.
Отредактировано: DarkRaider - 21 сентября 2019 10:45:01
+ 0.00 / 0
                                 
 
  adolfus
 
   
adolfus  
 
Например MS SQL (вполне себе классическая реляционная СУБД), "на пальцах":
Параметр1=Таблица1.столбец1
Параметр2=Таблица1.столбец2
Таблица1.столбец3=Текст(Скуль Update над параметром 1 и 2(обновить Таблицу2.Строку3=Параметр1+Параметр2)
Испольнить
Параметр1=Таблица1.столбец1*3
Таблица1.столбец3=Текст(Скуль Update над параметром 1 и 2(обновить Таблицу2.Строку4=Параметр1-Параметр2+2)
Испольнить

Отношения между таблицей 1 и 2 выражены процедурой?
Сущности очень фундаментально статичны?
Данные изменяются сами по себе?
Вы, любезный, помнится несколько постов назад вообще уверяли:\n\n
Вы уж определитесь в какую сторону грести, пожалуйста.
Вы уже на первом "Параметр1=Таблица1.столбец1" вылетите по нехватке памяти.
Нельзя просто так копировать столбцы куда бы то ни было из базы, чтобы с ними что-то делать, даже если они помещаются, потому что их содержимое volatile по определению. Помимо Васи с БД работает Коля, Петя, Света и еще стопятьсот юзеров – в любой момент данные в столбце могут поменяться или исчезнуть. Это к тому, что "данные изменяются сами по себе".
В любой момент схема отношений и ограничений в базе может быть изменена независимо от вас (например, в связи с добавлением таблиц и столбцов, связанных вторичными инлдексами) и перестанет соответствовать вашей объектной модели.
Еще очень интересный момент – нет статичного соответствия типов между вашим ОО-языком программирования и типами в БД – в любой момент времени в базе данных тип может изменить представление, например после ее обновления. В результате однажды Вы при получении данных из базы в объект получите мусор или мусор запишете в БД.
-0.03 / 1
                                   
 
  slavae
 
   
slavae   Россия
Москва
 
в любой момент времени в базе данных тип может изменить представление, например после ее обновления. В результате однажды Вы при получении данных из базы в объект получите мусор или мусор запишете в БД.
Если базу курочит стадо обезьян, она и для хранения данных будет непригодна )
Империя - это мир, и этой идеологии достаточно. Мы живём в самой лучшей стране в мире и все нам завидуют.
Одушевлённое Одевают, Неодушевлённое Надевают.
+ 0.04 / 2
                                   
 
  DarkRaider
 
   
DarkRaider   Россия
Москва
38 лет
 
Вы уже на первом "Параметр1=Таблица1.столбец1" вылетите по нехватке памяти.
Нельзя просто так копировать столбцы куда бы то ни было из базы, чтобы с ними что-то делать, даже если они помещаются, потому что их содержимое volatile по определению.

Вы, любезный, очевидно, про реляционные БД и классический скуль только в учебнике читали и то мимоходом.
СУБД поддерживающие классический скуль - не работают целиком со столбцами, а поскольку объяснял я "на пальцах" и без синтаксиса - не упоминал идентификаторов строк, можете добавить с текст для себя [Таблица1.строка1.столбец1].
Если кому то интересна реализация динамического скуль запроса на MS SQL могу привести этот же пример с полным синтаксисом.

На досуге можете почитать про "колоночные СУБД" для общего развития.

Цитата
Помимо Васи с БД работает Коля, Петя, Света и еще стопятьсот юзеров – в любой момент данные в столбце могут поменяться или исчезнуть. Это к тому, что "данные изменяются сами по себе". В любой момент схема отношений и ограничений в базе может быть изменена независимо от вас (например, в связи с добавлением таблиц и столбцов, связанных вторичными инлдексами) и перестанет соответствовать вашей объектной модели.
Верно, именно для разрешения всех этих проблем и предназначена СУБД, для этого есть всякие блокировки, слепки и прочие механизмы неповреждающего обновления данных. Вот только данные меняются НЕ САМИ, а ПО КОМАНДЕ ОТ ДРУГОГО ПОЛЬЗОВАТЕЛЯ.
Для того чтобы не "переставало соответствовать" надо нормально учить уроки в школе и писать в коде не "SELECT * FROM ...", а "SELECT поле1,...полеN FROM ...". В таком случае изменение схемы данных путём добавления столбцов или их перемещения - никак на функционал не влияет. Приблизительно тоже самое и с внутренними связями, индексами, ограничениями.

Цитата
Еще очень интересный момент – нет статичного соответствия типов между вашим ОО-языком программирования и типами в БД – в любой момент времени в базе данных тип может изменить представление, например после ее обновления. В результате однажды Вы при получении данных из базы в объект получите мусор или мусор запишете в БД.
И тут, мой дорогой друг, Вы, сели в лужу, потому, что приведение типов тоже проходят в младшей программистской школе, ну по крайней мере раньше проходили, когда тёплое!=мягкому, но Вы не похожи на представителей молодого поколения. Таки в скуле оно есть. Кстати тип SQL_Variant тоже есть. Вы в очередной раз напрасно натягиваете сову на глобус пытаясь смешать процесс хранения данных с процессом их обработки в коде.

Данные хранятся и управляются на сервере,а скуль команды, Вы, ему задаёте на клиенте (приложение, служба, клиент командной строки) - а посему при нарушении схемы типов, сервер просто НЕ ВЫПОЛНИТ сбойную инструкцию и, Вы, как клиент, НЕ ПОЛУЧИТЕ ответ (будь то выборка данных или код успешного выполнения команды).
Отредактировано: DarkRaider - 21 сентября 2019 17:00:01
+ 0.04 / 3
                                   
 
   
Andrew Carleet   Канада
Brampton
52 года
 
Вы уже на первом "Параметр1=Таблица1.столбец1" вылетите по нехватке памяти.
Нельзя просто так копировать столбцы куда бы то ни было из базы, чтобы с ними что-то делать, даже если они помещаются, потому что их содержимое volatile по определению. Помимо Васи с БД работает Коля, Петя, Света и еще стопятьсот юзеров – в любой момент данные в столбце могут поменяться или исчезнуть. Это к тому, что "данные изменяются сами по себе".
В любой момент схема отношений и ограничений в базе может быть изменена независимо от вас (например, в связи с добавлением таблиц и столбцов, связанных вторичными инлдексами) и перестанет соответствовать вашей объектной модели.
Еще очень интересный момент – нет статичного соответствия типов между вашим ОО-языком программирования и типами в БД – в любой момент времени в базе данных тип может изменить представление, например после ее обновления. В результате однажды Вы при получении данных из базы в объект получите мусор или мусор запишете в БД.
Все в нашей жизни относительно.
Можно просто запереть данные, над которыми работаем, хоть поле, хоть всю базу. И данные в столбце не поменяются и не исчезнут "в любой момент". Так делать нехорошо? Ну, кто спорит; но подобное встрачается.

Любые изменения схемы/структуры базы данных делаются после модификации и тестирования всех приложений, использующих эту базу. Опять-таки, можно зафигачить ALTER в середине дня и без предупреждения. Но обычно так не делается. Нынче DBA тоже под ITIL ходят.
Отредактировано: Andrew Carleet - 24 сентября 2019 02:27:19
Никогда не думал, что буду жить во времена, когда Микки и Дональд правят в США (из интернета)

"Это при Советской Власти можно было работать для души." (ц) тёща Портоса.
+ 0.00 / 0
                                     
 
  adolfus
 
   
adolfus  
 
Все в нашей жизни относительно.
Можно просто запереть данные, над которыми работаем, хоть поле, хоть всю базу. И данные в столбце не поменяются и не исчезнут "в любой момент". Так делать нехорошо? Ну, кто спорит; но подобное встрачается.
Не встречается. СУБД не позволит.
Никто не может заблочить поле более, чем на некоторое небольшое время, достаточное на выполнение операции чтения актуального содержимого и записи обновления. Вы просто не видите того, что происходит под капотом. А под капотом происходит нечто, похожее на следующее:
1. Вы делаете запрос на получение каких-то полей
2. СУБД "делает" вам запись , отправляет ее вам и сохраняет копию (либо у себя, либо на клиенте)
3. Вы там что-то смотрите, колупаетесь, правите
4. Вы отправляете обновление
5. СУБД выполняет что-то, типа такого
- поля, которые Вы запрашивали, блокируются на запись (после Вашего доступа и до этого момента их мог изменить кто угодно)
- получаются актуальные значения полей, которые Вы выбрали
- выполняется сравнение полученных с полученными ранее из копии
- если идентичны, ваши изменения уходят в базу (профит), блоки снимаются.
- в противном случае блоки снимаются, вы получаете отказ, и измененные после вашего запроса поля актуализируются в копии и вашей записи. Внесенные Вами изменения аннулируются
Вы вынуждены перейти к цифре 3.
В результате продолжительность действия блокировки много меньше, чем продолжительность Вашего взаимодействия с базой.
Мало того, помимо тех таблиц, что Вы лично накриэйтили, СУБД создаст в Вашей БД таблицы учета статистики обращений, откуда она будет корректировать максимальные длительности блокировок для разных запросов, чтобы аварийно завершать транзакции, превысившие лимиты.


Вероятность того, что данные изменятся, может быть мала, но это не отменяет события, а с учетом законов Паркинсона, вероятность данного события может даже превысить число \pi.
Отредактировано: adolfus - 25 сентября 2019 14:43:59
-0.04 / 2
                                       
 
  DarkRaider
 
   
DarkRaider   Россия
Москва
38 лет
 
Не встречается. СУБД не позволит.
Никто не может заблочить поле более, чем на некоторое небольшое время, достаточное на выполнение операции чтения актуального содержимого и записи обновления. Вы просто не видите того, что происходит под капотом. А под капотом происходит нечто, похожее на следующее:

Уважаемый, adolfus, уже становится забавным наблюдать полёт Вашей фантазии из головы, как в анекдоте про психолога и страшную жену ("... зато какие у неё кошмары!!!").

Цитата
1. Вы делаете запрос на получение каких-то полей
Таки после прочтения данных и отдачи результата действие СУБД на этом заканчивается. Операция атомарна - "прочитал на текущий момент времени".

Цитата
2. СУБД "делает" вам запись , отправляет ее вам и сохраняет копию (либо у себя, либо на клиенте)
3. Вы там что-то смотрите, колупаетесь, правите

Это Ваша персональная СУБД из головы делает Вам хорошо.

Цитата
4. Вы отправляете обновление
А вот это вторая операция "обновление". В зависимости от настроек базы она может быть атомарной одна или в группе, когда имеет место обновление нескольких связанных таблиц. Таблицы имеющие связи управляемые СУБД (ограничения, триггеры, связанные таблицы) - обновляются транзакционно. Так же режим транзакции легко включается вручную по мере надобности. Таковой режим позволяет объединить несколько операций чтения/записи в одну транзакцию, которая имеет свойства неделимости (атомарности) и общего результата (если выполнено успешно то всё, если ошибка где то - не выполнено ничего).


Цитата
5. СУБД выполняет что-то, типа такого
- поля, которые Вы запрашивали, блокируются на запись (после Вашего доступа и до этого момента их мог изменить кто угодно)
- получаются актуальные значения полей, которые Вы выбрали
- выполняется сравнение полученных с полученными ранее из копии
- если идентичны, ваши изменения уходят в базу (профит), блоки снимаются.
- в противном случае блоки снимаются, вы получаете отказ, и измененные после вашего запроса поля актуализируются в копии и вашей записи. Внесенные Вами изменения аннулируются
"горячечный бред", извиняюсь за мой французский.

Если поступает команда на ИЗМЕНЕНИЕ данных и нужная запись в данный момент заблокирована на запись другой сессией, команда встаёт в очередь и обновляет данные сразу после снятия первой блокировки.
Обновление данных - атомарно, если в момент физического обновления данных есть запрос на чтение - выдаются данные до вносимого изменения, до тех пор пока не будет подтверждено, что "данные изменены успешно". После этого на любой запрос будет выдаваться обновлённая информация.

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

Цитата
Вероятность того, что данные изменятся, может быть мала, но это не отменяет события, а с учетом законов Паркинсона, вероятность данного события может даже превысить число \pi.
Приятно, что, Вы, знакомы с "законами Паркинсона", хотя тут более уместны были бы "законы Мерфи".

Проблемы разсинхронизации данных не в том, что данные "изменятся", а в том "когда". Классическая картина - когда используются несвязанные средствами СУБД таблицы (2 таблицы, одна из которых содержит цифровой индекс из второй) а это очень распространённое явление, так как народ не любит делать связи управляемые СУБД, и происходит добавление данных(или обновление) в одну из таких связанных таблиц, но забывают организовать транзакцию со второй таблицей. В результате обновление этих таблиц получается не атомарно, а последовательно и разделено во времени. Следовательно возникает промежуток времени, в который может быть произведён запрос на чтение данных "между" обновлениями первой и второй таблицы. В результате операция будет выполнена (с точки зрения СУБД никаких противоправных действий не совершается) и будут отданы неверные данные (таб1 обновлена, а таб2 ещё нет).
Есть и другие сценарии, но этот происходит чаще всего. И это НЕ ошибка СУБД, это ошибка ПРОГРАММИСТОВ работающих с этой БД.

К слову, такая же ошибка может возникать и при командах чтения данных из связанных таблиц. Если не объединять их в транзакцию, можно прочитать данные в момент когда одна из связанных таблиц уже обновлена.

Если использовать связи управляемые СУБД - она будет автоматически следить за синхронизацией этих данных и на чтение и на запись.
Отредактировано: DarkRaider - 27 сентября 2019 13:30:01
+ 0.11 / 7
                                         
 
   
Быдлокодер  
 
"с обоими не согласен" . Ну или согласен - как смотреть.

Во первых, вы пытаетесь описать уровень "изоляция образа", хотя несколько странно. Ну ладно.
Далее. Все изменения данных в РСУБД (и нет, Dbase III не СУБД) делаются в рамках транзакции. Транзакция не включается вручную, когда надо - она есть всегда. Другое дело, что у вас может быть выставлен автокоммит - это по транзакции на sql выражение - и он для программиста на Дельфи, наверно, выглядит как "нет транзакции" (не писал на дельфях - не знаю).
Далее. В случае изоляции образа СУБД гарантирует, что транзакция видит слепок закоммиченныз данных на момент начала транзакции. Т.е. она действительно записть "делает" - но это вопрос в какой момент. Если изоляция реализована на теневых записях (а это не обязательно), то просто читается старая версия записи.
Далее. Клиент меняет данные. Дисциплина блокировки зависит от стратегии разрешения конфликтов. Если пессимистическая (оракл), то СУБД блокирует запись, и другие транзакции, которые хотят запись изменить/заблокировать, будут ждать снятия лока. Если оптимистическая (firebird), то запись не блокируется, а при конфликте по изменению прилетит облом в момент коммита.
После изменения записи лок (если был) снимается не сразу, а по окончании транзакции. Это нужно для того, чтобы была возможность откатить текущую транзакцию на случай, если кто-то ещё до нашего коммита попытается поменять запись - т.е. чтобы исключить грязную запись. Ну и если у нас изоляция транзакций на блокировках, либо уровень изоляции выше изоляции образа - тогда и чтение другим блокируем - ну там нюансы, да.
Ну и не забываем про явные блокировки - select for update, или вообще lock table in exclusive mode.
Так что вполне можно заблокировать что-то на время жизни нашей транзакции - т.е. относительно надолго.

Ссылочная целостность уже навернута поверх этих механизмов - декларативно там, триггерами, уникальными индексами и т.д. Её может и не быть, и к предмету вашего спора она, по большому счету, не относится.
Отредактировано: Быдлокодер - 27 сентября 2019 16:15:01
Кораблик космический
Летел и насвистывал
Дырочкой в правом боку.
+ 0.00 / 0
                                           
 
  DarkRaider
 
   
DarkRaider   Россия
Москва
38 лет
 
"с обоими не согласен" . Ну или согласен - как смотреть.
"Люблю и ненавижу"(песенка модного ныне певцуна)?

Цитата
Если оптимистическая (firebird), то запись не блокируется, а при конфликте по изменению прилетит облом в момент коммита.
Просто какая то глобальная идея о вселенском обломе.

Оптимистическая блокировка не ограничивает модификацию обрабатываемых данных сторонними сессиями, однако перед началом предполагаемой модификации запрашивает значение некоторого выделенного атрибута каждой из строк данных (обычно используется наименование VERSION и целочисленный тип с начальным значением 0). Перед записью модификаций в базу данных перепроверяется значение выделенного атрибута, и если оно изменилось, то транзакция откатывается или применяются различные схемы разрешения коллизий. Если значение выделенного атрибута не изменилось — производится фиксация модификаций с одновременным изменением значения выделенного атрибута (например, инкрементом) для сигнализации другим сессиям о том, что данные изменились. by Википедия

Цитата
Ссылочная целостность уже навернута поверх этих механизмов - декларативно там, триггерами, уникальными индексами и т.д. Её может и не быть, и к предмету вашего спора она, по большому счету, не относится.
Тему спора уже никто не помнит. Изначально был сказ о том как объектная парадигма несовместима с релиционным подходом к хранению и управлению данными.

Предлагаю желающим ознакомится с вики.
Тут виды блокировок.
А тут уровень изоляции транзакций
Странички небольшие и все варианты разруливания коллизий там описаны весьма конкретно. Так что изобретать не нужно.
+ 0.07 / 4
                                           
 
  slavae
 
   
slavae   Россия
Москва
 
Другое дело, что у вас может быть выставлен автокоммит - это по транзакции на sql выражение - и он для программиста на Дельфи, наверно, выглядит как "нет транзакции" (не писал на дельфях - не знаю).
"Домашний" сервер БД для Дельфи - Interbase, и уж это надо писать каким-то специальным образом, чтобы не знать, или не уметь управлять транзакциями на Интербейзе )
Империя - это мир, и этой идеологии достаточно. Мы живём в самой лучшей стране в мире и все нам завидуют.
Одушевлённое Одевают, Неодушевлённое Надевают.
+ 0.03 / 1
                           
 
  TAU
 
   
TAU  
 
представляются графами, а не деревьями
Справедливости ради, дерево - разновидность графа.
"Ольга Никаноровна проснулась в холодном поту. Ей привиделся кошмарный сон. Граф в виде дерева". Веселый
+ 0.06 / 3
                             
 
  adolfus
 
   
adolfus  
 
Справедливости ради, дерево - разновидность графа.
Справедливости ради, не разновидность, а подмножество одной из разновидности – ориентированного ациклического графа.
Дерево может представлять только самые простые отношения – иерархические, когда у объекта есть только одна входящая связь. Чтобы представить произвольную систему отношений на N объектах требуется в общем случае N деревьев, не имеющих общих ребер. Представлением сложной системы в виде набора таких деревьев управлять (добавлять/удалять вершины и связи) очень сложно.
+ 0.00 / 0
                           
 
  DarkRaider
 
   
DarkRaider   Россия
Москва
38 лет
 
Уважаемый, adolfus, вы фееричны как никогда!!!

Основная особенность всех СУБД, в том числе и реляционных, состоит в том, что никто не знает, какие действия и кем будут предприниматься над данными.
Я знаю доподлинно! Данные в базе данных можно добавить, удалить, считать или изменить. Автономную трансмутацию в СУБД пока не добавили. Все дальнейшие действия с данными могут быть произведены только после чтения их из хранилища. Область работы и ответственности СУБД в этом месте заканчивается.

Цитата
... В БД хранятся сущности и отношения между ними. И те и другие представляют непрерывно обновляемые динамические структуры данных...
Правда? Наиболее распространённый "частный" случай СУБД - это файловая подсистема любой ОС. Я правильно понимаю, что в файлах (как объектах хранения), постоянно перемещаются байтики туда сюда сами? Впрочем я совсем забыл про сбойные кластеры! Ведь информацию из них перемещает дисковая подсистема! Правда связи при удачном чтении сбойного сектора всё таки сохраняются, как и целостность объекта хранения.
+ 0.03 / 1
                   
 
   
Быдлокодер  
 
Это вряд ли. Поженить ООП и SQL пока еще никому не удалось – там противоречия на уровне парадигмы. Поэтому нет никакой необходимости в кишках и недрах СУБД писать что-то на С++ без классов, если тут же рядом есть С, на котором можно написать вообще все.
А для гиков и членов секты свидетелей ООП есть привязки к некоторой части интерфейса к СУБД и все счастливы.
Не-не, я не про объектно-реляционность.
Потроха реляционной СУБД отлично ложаться на объектную модель.
Ну, типа, источником данных может быть скан таблицы (с условием-без условия), скан листьев индекса (с условием-без условия), поиск в индексе, результат предыдущего шага исполнения запроса, какой-нибуть хэш-дистинкт, результат джоина, причем надо не забыть про порядок сортировки и использовать его дальше при исполнении запроса и т.д. - отлично на объекты ложится. Результат синтаксического разбора в виде дерева объектов. Транслированный запрос, который умеет себя сохранять или передвать по сети.. Ну и по мелочи внизу - объект на стеке с мутексом внутри, из функции вышли - мутекс отпустили...
Я люблю плюсы. Правда, всё как-то не складывается на них писать. Сплошной "папа может С"...
Отредактировано: Быдлокодер - 20 сентября 2019 08:45:01
Кораблик космический
Летел и насвистывал
Дырочкой в правом боку.
+ 0.00 / 0
                     
 
  DarkRaider
 
   
DarkRaider   Россия
Москва
38 лет
 
Не-не, я не про объектно-реляционность.
Потроха реляционной СУБД отлично ложаться на объектную модель.
...
Я люблю плюсы. Правда, всё как-то не складывается на них писать. Сплошной "папа может С"...

Когда имеешь дело с неопределёнными данными - в реализации приходится уходить на высокие уровни абстракции, там сложно обойтись без объектного подхода.
Вспомни как было легко работать с простыми типами (например с типизированными файлами). Но ровно до тех пор, пока мы точно знали состав записи (входящих в неё типов переменных).
Как только появляется variant в том или ином виде - начинается уже катавасия.
+ 0.00 / 0
                       
 
   
Быдлокодер  
 
Когда имеешь дело с неопределёнными данными - в реализации приходится уходить на высокие уровни абстракции, там сложно обойтись без объектного подхода.
Вспомни как было легко работать с простыми типами (например с типизированными файлами). Но ровно до тех пор, пока мы точно знали состав записи (входящих в неё типов переменных).
Как только появляется variant в том или ином виде - начинается уже катавасия.
Ммм - да нет, вполне обходишься С..
Процедурный код - он другой малость получается, но его вполне хватает.
Зато он лучше поддается статическому анализу "глазками". В плюсах зачастую пока отладчиком не встанешь - не разберешься какая из функций когда вызовется.
И ещё: костыль в процедурном коде смотрится не так страшно как костыль в объектном. Ну добавил ещё флажок или проверку - делов-то. А в плюсах может понадобиться перетряхнуть структуру классов.
Ну тут главное не заиграться, а то оглянуться не успел - а всё уже из костылей состоит.
Кораблик космический
Летел и насвистывал
Дырочкой в правом боку.
+ 0.05 / 2
           
 
  dmitriк62
 
   
dmitriк62   Россия
Москва
57 лет
 
Скрытый текст

Про уровни транзисторов в кристалле процессоров или протоколы взаимодействия с оперативной памятью я молчу. Так до какого уровня должны программисты знать всё, чтобы не быть быдлокодерами?

До того самого уровня, который ещё знает пользователь Марк№76.
Глубже — совершенно бесполезные для программиста знания...
Многие пытаются смотреть, куда идёт дым.
А надо бы - откуда ветер дует.
-0.01 / 1
       
 
   
Explorer-2000   Канада
 
Я не знаю, что там за курсы от MS, но зато знаю, что нынче на Украине полным полно "бывших домохозяек и грузчиков, которые вошлиВАйТитм" - этот спецтермин означает человека без хороших знаний логики, комбинаторики и дискретной математики, который научился выполнять определенные действия на компьютере и после этого все его называют "программистом": 1) он сам себя так называет, 2) окружающие его так называют, 3) работодатель его под видом программиста продаёт в качестве аутсорс-ресурса (в том числе и в Россию).
Но программистом этот человек не является, и сложные задачи он никогда не решит (это как раз тот случай, когда для решения сложной задачи будет принято очевидное простое и неправильное решение). Пользы от этого "большинства современных программистов" ровно столько же, сколько от "большинства продавцов-консультатов" в какой-нибудь евросети.
Так им никто такие задачи и не даёт, IT это огромная индустрия, где полно простой, рутиной работы вот там и достаточно программистов с базовыми знаниями.
+ 0.01 / 1
         
 
  Oleg K.
 
   
Oleg K.   Россия
Москва
34 года
 
Так им никто такие задачи и не даёт, IT это огромная индустрия, где полно простой, рутиной работы вот там и достаточно программистов с базовыми знаниями.
Кхм... Вы, мягко говоря, сильно ошибаетесь. Представьте, что есть два программиста: Ваня-программист за 3000р в час и Ваня-"программист" за 500р в час. Угадайте, кого выберет заказчик для типовой задачи. Правильно - тот вариант, который по-дешевле. Ну или можете не представлять, если вы сталкиваетесь с этим (я сталкиваюсь, поэтому у меня описание не "гипотетической ситуации", а вполне реальных проектов).
А потом все удивляются, почему от постоянной дешевизны одна страничка новостей на сайте загружается 3 секунды на 100МБитном канале и занимает в оперативной памяти 1 гигабайт.
Да, простые задачи часто делают программисты без большого опыта и знаний. Но если их оставить там одних (без присмотра более опытного коллеги), то они вам там понаработают Причём, я не думаю, что в другой области, где нужны знания и т.п. (например, в ремонте автомобилей тех же самых) трудовая деятельность сильно отличается - в конце концов, фразе "каждый суслик в поле - агроном" уже очень много лет.
+ 0.04 / 2
           
 
   
Быдлокодер  
 
Кхм... Вы, мягко говоря, сильно ошибаетесь. Представьте, что есть два программиста: Ваня-программист за 3000р в час и Ваня-"программист" за 500р в час. Угадайте, кого выберет заказчик для типовой задачи. Правильно - тот вариант, который по-дешевле..
Заказчик вообще не выберет Ваню. Заказчек выберет Джаймина. А Ване придется разгребать тот треш, который Драймин нагородит. Рррр.
Кораблик космический
Летел и насвистывал
Дырочкой в правом боку.
+ 0.06 / 3
     
 
   
Explorer-2000   Канада
 
Интересно, а какова польза нам от этого "большинства современных программистов" с 4-х недельными курсами MS? Их как-то можно использовать для решения внутрироссийских айти-проблем?
Кстати, а что такое "курсы MS"?
MS это MicrosoftВеселый, лет 15 назад были 4 недельных курса по .NET & SQL, которые в целом закрывали весь девелопмент, можно было работать, а через год, получив опыт получать на контракте порядка 100К$ в годПодмигивающий, хорошее время было, сейчас может эти направления и не актуальны так есть другие типа Angular или AWS, но суть то не меняется, да и в России вон Яндекс обещает массово готовить IT-шников, думаете они все будут на уровне математического факультете университетаНепонимающий, я вот думаю что это будет набор неких базовых знаний и только, но такие люди нужны на рынке.
-0.02 / 1
 
 
   
Быдлокодер  
 
А лучше всего вообще ни на что время не тратить, а сразу юзать STL. Или еще лучше, ничего не программировать, просто использовать готовое.
Вы когда нибудь задумывались, что вроде как постоянно растет производительность железа, объем памяти, а приложения становятся все более тормозными? А потому, что нечего время тратить на изучение структур данных и алгоритмов, языков низкого уровня, а сразу в котлин, скалу и пайтон.
Угу. Собеседовал кандидата, который пишет драйвера для Линукса, но не представляет себе как устроен список. Ну а что - есть же готовые макросы. Разумеется, про O(n) не слышел (а это, кстати, точно в школе проходят).
Электронщик по образованию, ага. Военка.
Вообще, по моему опыту, радиотехники по образованию обычно посредственные программисты. Хоть железо знают, да.
Вот физики - попадаются хорошие. Но лучше все-таки профильное образование.
Кораблик космический
Летел и насвистывал
Дырочкой в правом боку.
+ 0.00 / 0
 
   
Explorer-2000   Канада
 
Нет - и не надо. Этот способ сортировки - зло. Нечего время тратить, чтобы узнать, как не стоит делать. Лучше сразу - как стоит.
И это говорит преподаватель в униерситетеНепонимающий в учебном плане несомненно представляет как пример не эффективного алгоритма.
+ 0.00 / 0
 
  AndreyK-AV
 
   
AndreyK-AV   Россия
Уфа
58 лет
 
Нет - и не надо. Этот способ сортировки - зло. Нечего время тратить, чтобы узнать, как не стоит делать. Лучше сразу - как стоит.
Даже на уровне школы при преподавании информатики стоит вопрос, а что преподавать, и на что упор, на технологии или науку!?
Если технологии первичны, то результат быстр, а способы сортировки согласно методике типа тому чему сейчас научили... для большинства пользователей и кодёров достаточно...
А если как науку, то первична математика, физика и химия с биологией не помешают, но после первых двух наук, дабы понимали физическую суть явлений, имели качественный математический аппарат, и тогда способ "сортировки" выберут сами согласно задачи, порой лучшей чем советуют преподаватели....
Ах да, логику давать надо и в любом варианте.Подмигивающий
"Не умирают гарибальдийцы, один упал, а два встают"
"Лучше умереть стоя, чем жить на коленях".
-------------------------------------------------------------
Наше дело правое. Враг будет разбит. Победа будет за нами.(с)
+ 0.05 / 5
 
   
Быдлокодер  
 
Нет - и не надо. Этот способ сортировки - зло. Нечего время тратить, чтобы узнать, как не стоит делать. Лучше сразу - как стоит.
Это все-таки уже первый курс. Вы же не требуете, чтобы в школе учили аналитическую геометрию?
Кораблик космический
Летел и насвистывал
Дырочкой в правом боку.
+ 0.00 / 0
 
 
  Senya
 
   
Senya   Россия
50 лет
 
Это все-таки уже первый курс. Вы же не требуете, чтобы в школе учили аналитическую геометрию?
По большому счёту сортировка пузырьком это ещё даже не уровень алгоритмов. Это уровень изучения базовых операций, копирования, сравнения, ветвления на простейшем примере. Алгоритмы будут позже.
"Иван Грозный помещает на рабочий стол полученный от хана ярлык."(с) Не моё.
+ 0.07 / 6
НОВОСТИ ПАРТНЕРОВ

AFTERSHOCK

     
  1. >
  2. Блог >
  3. TAU >
  4. Что нужно знать программисту
Глобальная Авантюра © 2007-2019 Глобальная Авантюра. Все права защищены и охраняются законом. При использовании любого материала любого автора с данного сайта в печатных или Интернет изданиях, ссылка на оригинал обязательна. Мнение администрации не обязательно совпадает с мнением авторов документов и комментариев, опубликованных на сайте.

CCBot/2.0 (https://commoncrawl.org/faq/)
Unknown

Яндекс.Метрика