В MSSQL длина заявленной varchar на производительность либо не влияет, либо влияет так слабо, что я не смог это отследить.
Если в колонке varchar (10) и varchar (400) находятся строки по 10 символов — то скорость работы выборок и поиск по ним — не изменяется.
И в целом, рассказать о производительсноти MSSQL можно гораздо больше! Автор, исследуй вопрос!
«Все уже украдено до нас» (с)
Для интересующихся — гуглить по строкам EAV и модель Тенцера.
Основной минус такой технологии — производительность. Падение производительности от порядка до 20, 30 раз из-за отсутсвия оптимизаций СУБД по такой модели хранения, отсутсвия индексов по двум и более полям, проблем чтения при количестве записей от ста тысяч и т.д.
Основной плюс — однотипность разработки для таких задач, как: переменное колиество атрибутов объекта, хранение истории объекта, однотипная обработка изменения объекта, однотипный подход к аудиту и т.д.
Для MSSQL и ORACLE рекомендую рассмотреть возможность хранения данных в XML полях.
Спасибо за статью!
Кстати, цикл с простыми числами можно сократить до корня, и проверять хотя бы с шагом два (отбросив четные). А можно и еще быстреее :)
Ребята, не зовите Долгова. Его интервью довольно невнятны, он не раскажет нам ничего о планах Гугл. Скорее всего раскажет о новых функциях ГуглМэп в России. Предлагаю звать Воложа!
Хорошо бы в начале статьи в один абзац написать, что такое Generic-класс и зачем он нужен. А всю реализацию, в том числе описание преимуществ данного примера — подкат.
А то вдруг на главную страницу выйдет, то не всем может быть понятно о чем статья.
Законно ли это:
Если компания предупредила Вас о установке программы - законно. Компьютеры их – что хотят то и ставят.
Если не предупредила... в общем-то, законно тоже. Можно попробовать напирать на то, что обычай делового оборота предполагает возможность нахождение личной информации на рабочих компьютерах и компания ее незаконно похищает. Но, скорее всего суд встанет на сторону компании, опять таки см. предыдущий пункт.
Будет ли это работать:
Чего хочет компания? Да уж всяко не «прижать» работягу. Причина проста: для работников умственного труда очень трудно оценить, на сколько сильно загружен человек. Для такой оценки нужен отельный специалист, а у них только есть один web-программист и один администратор на зарплате. Вот и делаются попытки… Руководители тоже люди, и им тоже иногда кажется :)
Демотивация – особенно на первых порах, обеспечена. Программистов так зажимать – нельзя, секретарш, можно попробовать, но и это будет не самый лучший ход работодателя. Если уж кажется, что работник Вас обманывает и говорит о своей 100% нагрузке, тогда как сам половину времени играет в игры, можно с его согласия сделать месячный мониторинг, и опять таки, вместе отследить изменение производительности за время мониторинга.
А какое решение для работодателя правильное?
Совсем правильно: все неспециализированную деятельность отдавать на аутсорс. Если вы не специалист по постановкам задач и оценки времени программиста – то и загрузить работой качественно не сможете. Уберите из своей деятельности все, что не является Вашей уникальностью, как компании. Отдайте разработку сайта, поддержку сети в офисе и бухгалтерию на аутсор! Это будет дешевле!
Я программер. В коде вижу косяк с >=0
Других моментов, которых можно назвать косяками - не вижу. Все остальное может быть объяснено.
Автор, плиз, скажи, а где здесь бред?
Напиши код, который не использует автоинкримент (по разным причинам это может быть нужно), как-то отработает в случае, если в запросе вывалится в исключение (нет таблицы, прав или соединения с базой данных), если запрос вернет пустое количество строк или действительно вернет значение.
Может в PHP есть это все одной командой?
У этой архитектуры есть недостаток - два объекта могут быть связаны только одной связью.
Например, У фотографии могут быть два атрибута: кто добавил, и кто последний редактировал. Оба атрибута ссылаются на объект типа "пользователь", и оба этих пользователя могут быть одним человеком.
Добавляйте пятую колонку - тип связи. И таблицу - типы связей.
Было бы интересно сравнение по производительности с классическими методами.
Например, я хочу выбрать всех потомков элемента, или всех родителей до корня. Что быстрее, использование нового подхода MSSQL2008 или хранение иерархии в четыре столбца: Id, parentId, startId, finishId с классическим запросом на принадлежность элемента диапазону??
Если в колонке varchar (10) и varchar (400) находятся строки по 10 символов — то скорость работы выборок и поиск по ним — не изменяется.
И в целом, рассказать о производительсноти MSSQL можно гораздо больше! Автор, исследуй вопрос!
Для интересующихся — гуглить по строкам EAV и модель Тенцера.
Основной минус такой технологии — производительность. Падение производительности от порядка до 20, 30 раз из-за отсутсвия оптимизаций СУБД по такой модели хранения, отсутсвия индексов по двум и более полям, проблем чтения при количестве записей от ста тысяч и т.д.
Основной плюс — однотипность разработки для таких задач, как: переменное колиество атрибутов объекта, хранение истории объекта, однотипная обработка изменения объекта, однотипный подход к аудиту и т.д.
Для MSSQL и ORACLE рекомендую рассмотреть возможность хранения данных в XML полях.
Кстати, цикл с простыми числами можно сократить до корня, и проверять хотя бы с шагом два (отбросив четные). А можно и еще быстреее :)
При публикации видео на youtube можно как-то ограничивать его видимость по странам? Кто-нибудь видел такой интерфейс?
– Не хочу! Опять Иванов приставать будет, и Сидоров кнопки на стул класть.
– Вася, надо! Ты же директор.
А то вдруг на главную страницу выйдет, то не всем может быть понятно о чем статья.
Буду использовать.
Я знаю о ней:
1. ты ее называешь Ключевые сущности и наследники
2. тебе она нравится в последнее время
Искал в Гугле и кроме как в твоих топиках не встретил такого названия.
Она официально называется иначе? Или ты сам придумал ;)
Если компания предупредила Вас о установке программы - законно. Компьютеры их – что хотят то и ставят.
Если не предупредила... в общем-то, законно тоже. Можно попробовать напирать на то, что обычай делового оборота предполагает возможность нахождение личной информации на рабочих компьютерах и компания ее незаконно похищает. Но, скорее всего суд встанет на сторону компании, опять таки см. предыдущий пункт.
Будет ли это работать:
Чего хочет компания? Да уж всяко не «прижать» работягу. Причина проста: для работников умственного труда очень трудно оценить, на сколько сильно загружен человек. Для такой оценки нужен отельный специалист, а у них только есть один web-программист и один администратор на зарплате. Вот и делаются попытки… Руководители тоже люди, и им тоже иногда кажется :)
Демотивация – особенно на первых порах, обеспечена. Программистов так зажимать – нельзя, секретарш, можно попробовать, но и это будет не самый лучший ход работодателя. Если уж кажется, что работник Вас обманывает и говорит о своей 100% нагрузке, тогда как сам половину времени играет в игры, можно с его согласия сделать месячный мониторинг, и опять таки, вместе отследить изменение производительности за время мониторинга.
А какое решение для работодателя правильное?
Совсем правильно: все неспециализированную деятельность отдавать на аутсорс. Если вы не специалист по постановкам задач и оценки времени программиста – то и загрузить работой качественно не сможете. Уберите из своей деятельности все, что не является Вашей уникальностью, как компании. Отдайте разработку сайта, поддержку сети в офисе и бухгалтерию на аутсор! Это будет дешевле!
Других моментов, которых можно назвать косяками - не вижу. Все остальное может быть объяснено.
Автор, плиз, скажи, а где здесь бред?
Напиши код, который не использует автоинкримент (по разным причинам это может быть нужно), как-то отработает в случае, если в запросе вывалится в исключение (нет таблицы, прав или соединения с базой данных), если запрос вернет пустое количество строк или действительно вернет значение.
Может в PHP есть это все одной командой?
Например, У фотографии могут быть два атрибута: кто добавил, и кто последний редактировал. Оба атрибута ссылаются на объект типа "пользователь", и оба этих пользователя могут быть одним человеком.
Добавляйте пятую колонку - тип связи. И таблицу - типы связей.
Например, я хочу выбрать всех потомков элемента, или всех родителей до корня. Что быстрее, использование нового подхода MSSQL2008 или хранение иерархии в четыре столбца: Id, parentId, startId, finishId с классическим запросом на принадлежность элемента диапазону??