Сколько примерно будет стоить?

[Orshansky]

спецы по SQL "уже не в теме"

Мадмуазель, звучит примерно как: "спецы" по XML, XSL, JSON, LATEX... может еще по TXT "спецы" актуальны?

...
А если серьезно, то знание SQL не устареет....

SQL ориентирован на работу с реляционными базами данных. Как только реляционная модель баз данных, которая имеет массу недостатков не будет отвечать требованиям современных программных систем - устареет и сам язык. Те же Bigtable (Google), MongoDB (Twitter)... - No-SQL базы данных. Поэтому, если серьезно, не стоит искусственно ограничивать себя одной единственной технологией.

Вот рассказывали чуваку в универе про SQL, а тут уже LinQ

SQL like синтаксис, только на порядок более бедный, чем SQL синтаксис того же PostgreSQL, Oracle... Сама концепция LINQ использует конструкции из функциональных языков, в итоге получаем смесь бульдога с носорогом - императивное программирование с элементами запросов к базам данных в функциональном стиле. Лично мне функциональная парадигма ближе, но для этого есть Haskell и HSQL. Лично мое мнение LinQ - мертвая технология, направленная на облегчение труда программиста, а следовательно позволяет использовать программистов с низкой квалификацией. Это не принципиально новая или революционная технология, это искусственная деградация SQL от Microsoft.

 

[dr_mousefly]

SQL like синтаксис, только на порядок более бедный, чем SQL синтаксис того же PostgreSQL, Oracle... Лично мое мнение - мертвая технология, направленная на облегчение труда программиста, а следовательно позволяет использовать программистов с низкой квалификацией. Это не принципиально новая или революционная технология, это искусственная деградация SQL от Microsoft.

Герцог как всегда упускает из виду множество неудобных ему фактов.
Например то, что LINQ to Objects исправляет один из важнейших недостатков ООП - отсутствие декларативного языка запросов к множествам объектов.
Изначальная дурость - сравнивать SQL и LINQ вообще.

распараллеливание (PLinQ), облачные вычисления, многоядерность...

нарастание энтропии на ровном месте..

 

[Renegade]

герцога залошили в сетях- он перебрался в кодинг

 

[@V.A.M.P.I.R@]

Всем спасибо уже разобрался,что и как делать,тему можно закрывать

 

[Orshansky]

Герцог как всегда упускает из виду множество неудобных ему фактов.
Например то, что LINQ to Objects исправляет один из важнейших недостатков ООП - отсутствие декларативного языка запросов к множествам объектов.

Что по этому поводу писал ваш кумир Гитлер? Вы процитировали пост, редактирование которого я не завершил. Прочтите еще раз.

 

[dr_mousefly]

Вы процетировали пост, редактирование которого я не завершил. Прочтите еще раз.

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

Что по этому поводу писал ваш кумир Гитлер?

Он писал, что герцог так и не ответил на вопрос "следует ли считать психически больными авторов статьи Mein Kampf в Википедии"..

 

[Orshansky]

Он писал, что герцог так и не ответил на вопрос "следует ли считать психически больными авторов статьи Mein Kampf в Википедии"..

Цитировать психически-больного человека, которым являлся Гитлер, человек с нормальной психикой не будет.

 

[Hisp]

А тут не в этом дела. Это классика: знания устаревают до того, как успеваешь выйти из универа...
Вот рассказывали чуваку в универе про SQL, а тут уже LinQ Понятное, что одно, другое только дополняет. Но всёравно даже очень хорошо зная SQL - ты уже не в теме... Кинься учить LinQ - не успеешь - распараллеливание (PLinQ), облачные вычисления, многоядерность... Опять не в теме будешь
В весёлое время живём, лучше ничего не учить

Я говорил о том, что такая работа с sql совсем не тянет на дипломную работу.

Это не принципиально новая или революционная технология, это искусственная деградация SQL от Microsoft.

Казалось бы, при чем ИмперияЗла(несомненно) к ОРМам?

 

[dr_mousefly]

Цитировать психически-больного человека, которым являлся Гитлер, человек с нормальной психикой не будет.

то есть авторы статей в Википедии - психически больные. формально логично. что и требовалось.
к слову, а каким психическим заболеванием болел Гитлер?

 

[Orshansky]

то есть авторы статей в Википедии - психически больные. формально логично. что и требовалось.
к слову, а каким психическим заболеванием болел Гитлер?

Шизофрения. На самом деле врожденная предрасположенность многочисленных членов семьи Гитлера и самого Гитлера к психическим заболеваниям была хорошо известна в высших эшелонах власти Германии.

 

[dr_mousefly]

Шизофрения.

пруф??

а авторы Википедии тоже ей от цитат заразились?

к слову, а вот если мне надо выбрать из коллекции объекты по условию,
Вы мне разрешаете пользоваться LINQ или надо по старинке перебирать в цикле?

 

[Orshansky]

пруф??
а авторы Википедии тоже ей от цитат заразились?

Потрудитесь поискать сами по ключевым словам: Психология Гитлера. Я не намерен вести тут пропаганду идиотов.

к слову, а вот если мне надо выбрать из коллекции объекты по условию,
Вы мне разрешаете пользоваться LINQ или надо по старинке перебирать в цикле?

Все зависит от задачи. Если это курсовой проект - разрешу. Если промышленная высоконагруженная система - то нет.

 

[dr_mousefly]

Все зависит от задачи. Если это курсовой проект - разрешу. Если промышленная высоконагруженная система - то нет.

а чиво? тот же самый цикл в исполнении компилятора не так кошерен?

- Сегодня мы будем разгружать зерно вилами
- А можно косой?
- Можно. лишь бы вы заебались
(ц)

Потрудитесь поискать сами

И в этом весь герцог. А механизм заражения шизой через цитаты там тоже описан, гарантируете это?

 

[Orshansky]

а чиво? тот же самый цикл в исполнении компилятора не так кошерен?

Ну вот например реальная задача:

1. Серверная часть, будет реализована на С/С++ и будет работать под управлением *nix/*bsd системы. А все оперативные данные будут храниться в собственном формате данных на базе ускоряющих структур в оперативной памяти для обеспечения времени выборки не более: 50 мкс (например: - таблица маршрутизации, активные сессии...).
3. Если говорить об интерфейсе то два варианта:
- Java
- собственный Web-сервер на С/С++ + например Yahoo GUI library.
Но в обоих вариантах взаимодействие с БД будет вестись через OLAP (в простейшем враианте Mondrian).
4. Занесение не агрегированных данных в промежуточную не реляционную БД будет осуществляться по протоколу через демон-менеджер на С/С++. Такие демоны должны иметь возможность устанавливаться в отказоустойчивый кластер с возможностью балансирования нагрузки например с помощью стандартных средств Linux - LVS.
5. Ну, а собственно агрегированные данные будут заноситься в основную БД, которая по всей видимости будет реализована на базе PostgreSQL/Oracle кластера, c которым будет работать исключительно специалист по базам данных c использованием наиболее оптимальных средств PostgreSQL/Oracle .

Так вот, где вы видите в этом достаточно не сложном проекте место для LINQ?

Лично я вижу применимость LINQ исключительно для курсовых проектов. Впрочем, даже в этом случае я бы рекомендовал смотреть в сторону Haskell/HSQL.

 

[Ferox]

Мне вообще кажется ущербной мысль, что современные технологии обработки данных (будь то базы данных, программирование, визуальное представление) нужно "изучать". Их нужно применять. Технологии изначально выдумываются так, что время которое требуется на их изучение пренебрежимо мало.

Тратить то или иное время бывает требуется на изучение не технологии как таковой, а конкретного прикладного средства имплементирующего технологию. То есть изучать не ХТМЛ, а то так Опера интерпретирует некоторые особенности ХТМЛ. Изучать не ПХП а структуру хуков в АПИ Друпал и т.п.

 

[dr_mousefly]

Впрочем, даже в этом случае я бы рекомендовал смотреть в сторону Haskell/HSQL.

Каждый кулик свое болото хвалит..

Так вот, где вы видите в этом достаточно не сложном проекте место для LINQ?

а где Вы видите место для цикла по коллекции объектов?
или предыдущий вопрос уже выпал из головы напрочь?

 

[Orshansky]

а где Вы видите место для цикла по коллекции объектов?
или предыдущий вопрос уже выпал из головы напрочь?

Объекты в ООП и данные в реляционной БД имеют разную природу именно поэтому, согласовать их за счет введения в императивные языки элементов функциональной парадигмы призван LINQ, который фактически является имитацией элементов ФП в ООП. Я не вижу смысла в изучении переходных технологий на стыке ООП и ФП. Либо ООП в чистом виде, если не устраивает по ряду причин - используйте ФП. Так вот для решения этой тривиальной задачи я вообще не вижу смысла привлекать ООП, а в функциональном программировании такого понятия как цикл - нет в принципе.

 

[dr_mousefly]

Объекты в ООП и данные в реляционной БД имеют разную природу именно поэтому, согласовать их за счет введения в императивные языки элементов функциональной парадигмы призван LINQ, который фактически является имитацией элементов ФП в ООП. Я не вижу смысла в изучении переходных технологий на стыке ООП и ФП. Либо ООП в чистом виде, если не устраивает по ряду причин - используйте ФП. Так вот для решения этой тривиальной задачи я вообще не вижу смысла привлекать ООП, а в функциональном программировании такого понятия как цикл - нет в принципе.

ну вот.

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

прикажете бегать цикликом по коллекции пунктиков только потому, что LINQ - это "плохо"?
или пихать птичечки во временную таблицу БД и потом поднимать количество отмеченных запросом?
или может есть волшебное решение на Haskell? особенно реализация экранного списка пунктиков интересует..

*какбе задача не из серии курсовых работ и является частью "высоконагруженной промышленной системы", причем не сферической и не в вакууме.

 

[Orshansky]

ну вот.

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

прикажете бегать цикликом по коллекции пунктиков только потому, что LINQ - это "плохо"?
или пихать птичечки во временную таблицу БД и потом поднимать количество отмеченных запросом?
или может есть волшебное решение на Haskell? особенно реализация экранного списка пунткиков интересует..

Если в рамках ООП: Java,C++ - то да, представьте себе, что это будет цикл. В рамках императивных языков других вариантов нет. В F#/Haskell список будет, а цикла нет. Вы же поймите, что LINQ - это всего лишь имитация элементов ФП в ООП.

А вы этого не понимаете, вам как обезьянке убрали цикл. Обезьянка даже не поняла, что это всего лишь одно из сотен достоинств ФП и обезьянка продолжает строчить на убогом С#...

 

[Hisp]

Так в чем же ужас совмещения ООП с элементами ФП?