левак из маркета PHP, PERL ($500-$1000).
а за 1200 не надо? 
любопытно, как это можно знать php без perl'а?
Легко . Так исторически сложилось . Просто посадили както на проект написанный на пхп+С - и сказали :"Это теперь твой проект" . Вот и сижу ......
которые имеют отдаленное представление об html.А кто требует от програмиста знание HTML ? Ты ещё доскональное знание JS потребуй......... Это работа верстальщика . Если дизайнер нарисует , верстальщик сверстает , то на основе этого шаблоны сделать .......... Веб-програмер должен в HTML+JS разбираться , должен знать что на этом сделать можно , должен это уметь это делать в случае какой-либо "жопы" , но опыт (умения это быстро сделать) - это уже немного не из той области......
> Ты ещё доскональное знание JS потребуй
Ну не обязательно досканальное, но если ты называешь себя web-программист, то выпадающую менюшку под оба браузера ты уж наверное написать сможешь. Еще мы на собеседовании обычно просим написать не сложный SQL запрос, в котором таблицу надо саму с собой связать. Почти никто не может.
Хотя в резюме пишут: Базы данных, Оракл в полный рост и т.п. 
Ну не обязательно досканальное, но если ты называешь себя web-программист, то выпадающую менюшку под оба браузера ты уж наверное написать сможешь. Еще мы на собеседовании обычно просим написать не сложный SQL запрос, в котором таблицу надо саму с собой связать. Почти никто не может.
Хотя в резюме пишут: Базы данных, Оракл в полный рост и т.п. Ну оракл я к примеру не знаю . Сложный SQL запрос я например напишу , но если нормально спроектированна база под конкретный проект , то там все запросы простые. Сложные нужны только в "редкоиспользуемых" случаях (например какой нибудь администраторский интерфейс) , но и там зачастую информацию проще получить "по ссылке на объект" из предыдущего запроса и сотваить новый простой запрос. А на счёт менюшек - под 1 браузер я например менюшку напишу сразу , под второй подгонять надо , но ,ИМХО , этим верстальщики должны заниматься. Со стороны программиста - обеспечить информацией "эту менюшку" . И если при устройстве на программера от меня будут требовать писать JS скрипты - то проще на текущей работе остаться , потихоньку С++ осваивать , хоть и за копейки. По моему веб-программеры бывают 2 типов - серверный язык+ клиентская часть(браузер) или простой серверный язык + углублённое знание серверной части ............
ЗЫ Sorry если мои высказывания ламерскими кажутся , это не более чем ИМХО , и опыт работы у меня только с 1 проектом ...........
ЗЫ Sorry если мои высказывания ламерскими кажутся , это не более чем ИМХО , и опыт работы у меня только с 1 проектом ...........
Нет, стуктура данных должна быть спроектирована правильно, а не так, чтобы запросы простыми получались.
А я и не говорил что от "простоты запросов" отталкиваться надо. Но ,как правило , при правильной структуре , запросы простыми получаются.
ЗЫ Поясни что ты подразумеваешь под "правильной структурой" . Под что именно эта структура должна быть оптимизированна? Вариант "макимально быстро отдавать наиболее часто запрашиваему информацию" не катит?
ЗЫ Поясни что ты подразумеваешь под "правильной структурой" . Под что именно эта структура должна быть оптимизированна? Вариант "макимально быстро отдавать наиболее часто запрашиваему информацию" не катит?
простые запросы получаются при простых данных и простых связях. с увеличением количества связей - сложность запросов растёт, естественно. проектирование не имеет никакого отношения к простоте запросов.
Вероятно, катит, если это критично. Но по личному опыту знаю, что отечественный производитель очень любит вместо покупки ещё одного сервера нанять Васю Пупкина, который всё "оптимизирует". В итоге получается в разы дороже, а если с учётом последующих затрат на сопровождение - в десятки раз дороже.
Кроме того, "масимально быстро отдавать" как правило успешно решается уже вне БД.
Вариант "макимально быстро отдавать наиболее часто запрашиваему информацию" не катит?
Вероятно, катит, если это критично. Но по личному опыту знаю, что отечественный производитель очень любит вместо покупки ещё одного сервера нанять Васю Пупкина, который всё "оптимизирует". В итоге получается в разы дороже, а если с учётом последующих затрат на сопровождение - в десятки раз дороже.
Кроме того, "масимально быстро отдавать" как правило успешно решается уже вне БД.
простые запросы получаются при простых данных и простых связях. с увеличением количества связей - сложность запросов растёт, естественно. проектирование не имеет никакого отношения к простоте запросов.
Еще раз повторяю - мой реальный опыт - 1 проект . Правда весьма не маленький проект.Не я его изначально писал - но я его уже значительно переделал/доделал. Там в SQL хранится только часть информации (там даже заголовки писем вынесены из SQL - Postgre с ними не справлялся) .С базами на много десятков таблиц я не работал , и не могу даже представить где могут использоваться такие базы. Мне SQL в объёме Груббера с некоторыми Postgre-совскими фишками на этот проект хвататет.
Но по личному опыту знаю, что отечественный производитель очень любит вместо покупки ещё одного сервера нанять Васю Пупкина, который всё "оптимизирует".
или заказать в нормальной фирме , а не дизайн-студии имени Васи Пупкина.Которая всё нормально спроектирует , организует , разместит на своих мощностях и поддерживать будет. Клиенты тоже деньги учатся считать.........
базами на много десятков таблиц
несколько сотен таблиц - обычное дело
Ткни ссылкой (раз это веб проект значит должно быть "отображение" его в инете) на какой нибудь такой проект , где эти сотни таблиц реально необходимы.
ЗЫ Ссылок на mail.ru , yandex.ru и подобные "монстрообразные" сайты не надо .
ЗЫ Ссылок на mail.ru , yandex.ru и подобные "монстрообразные" сайты не надо .
в r/3 20k таблиц :ъ
зачастую информацию проще получить "по ссылке на объект" из предыдущего запроса и сотваить новый простой запрос.
Проще, не означает лучше.
По "книжному" таблиц должно быть столько, сколько есть сущностей. Не могу себе представить проект, где будет несколько сотен разных сущностей.
По "книжному" таблиц должно быть столько, сколько есть сущностей.Это не правда. По Дейту похожие сущности могут объединяться в одну таблицу. Сложная сущность может быть представлена несколькими таблицами, а кроме того некоторые связи требуют создания дополнительных таблиц. Таким образом количество таблиц и количество сущностей не связаны ни одним из знаков {'<', '>', '<=', '>=', '=', '<>'}
Оставить комментарий
stm2477274
любопытно, как это можно знать php без perl'а?Мы такого парня на ~800$ уже пол года ищем. В основном на собеседование приходят "web-программисты", которые имеют отдаленное представление об html.