В частности, на одной из машин SQL Server начал внезапно отвечать результатами тестовой схемы (вместо основной). Возможно, косяк какой-то конкретной версии dblib, пока не было времени оттестить.
@nepster09 Если мы говорим об обычных тегах - то таки да, это many-many.
Заработало оно вероятнее всего потому, что ранее Вы где-то ошиблись с написанием запроса, и Yii выполнил классический финт ушами "выполнить в два запроса без джойна".
@saroff На самом деле совокупная стоимость владения (железо + софт + время на мозготрах) у макбуков меньше, чем у остальных компов. И до версии 10.7 я всячески агитировал за макось, поскольку более удобной и стабильной системы просто не было.
Сейчас у меня 10.9, и я пока не готов за нее агитировать. При Джобзе такой фигни не было.
С другой стороны, виндовз серьезно поднялась, возможно имеет смысл глянуть из последние наработки.
@Nikobraz отвечу так: админ БД - он как менеджер проекта: хрен знает, зачем нужен, пока не поработаешь с грамотным специалистом.
Ну, примерно как всю жизнь писать код в notepad и ворчать: "да зачем мне эти ваши IDE, мороки только с ними...". А потом как-то раз попробовать IDE - ухты, удобно!
К примеру, с хорошим админом можно поговорить: мол, хочу такую-то штуку сделать, не выходит каменный цветок. А он тебе: чего ты паришься, давай я такое-то расширение поставлю, будешь запрашивать json, а получать симпатичных жирафчиков.
Что же касается оплаты - ну, данные обычно дороже кода стоят :)
@Snewer дохрена производительный, поскольку max(id) чаще всего либо хранится в метаданных, либо можно из индекса слямзить по-быстрому. А вот сортировка - сравнительно пакостная операция.
Впрочем, если сделаете скоростной тест на реальных данных - думаю, всем будет интересно.
К тому же, с учетом пропусков в ID, вероятность появления дублей резко повышается.
Простой пример: таблица всего с двумя записями: ID = 1 и ID = 100 (промежуточные удалили).
Соответственно, все рандомные id из интервала [2..99] будут превращаться в ID = 1.
@Snewer RAND() * MAX(id) может сгенерить два одинаковых значения.
Пример: допустим, максимальный id в таблице равен 100. RAND выдает два значения: 0.501 и 0.502 (знаков после точки, разумеется, больше, но суть понятна).
RAND * MAX даст нам 50.1 и 50.2, что при округлении даст два id = 50.
Предположим, первая таблица - это тексты какие-то, а вторая - это словарь к ним. Тогда я бы сделал так: вторая таблица имеет вид (id, слово[, нормальная форма]), связь через пивот-таблицу (id_текста, id_слова, частота). Соответственно, при размещении нового текста (или обновлении существующего) фоновый обработчик разбивает текст на слова, ищет их во второй таблице (в перспективе - по нормальной форме) и создает связь в пивот-таблице.
Если требуется дополнительно хранить порядок следования - тут уже думать надо.
@spatNeHochu для простоты предположим, что дизайнер, верстальщик и программист примерно одинакового профессионального уровня ("убили одинаковое количество времени на обучение").
Ну, то есть, пока программисты учатся программировать, дизайнеры учатся рисовать, и так далее.
Поэтому измеримой величиной является затраченное на задачу время (с учетом того, что человек является профессионалом и, условно говоря, не гуглит по три часа каждую элементарную задачу)
Больше всего вопросов тут, конечно, к такому члену команды, как "менеджер проекта". В идеальном сферическом мире это тоже профессия, на которую надо учиться (довольно долго и дорого). В реальности же чаще можно встретить людей, которые просто ничего не умеют, поэтому думают, что могут руководить.
Постоянно вижу такие диалоги:
- Ищу дизайнера, верстальщика и программиста для крутейшего стартапа за долю в проекте!
- А ты сам-то кто и чем будешь заниматься?
- А я буду разрабатывать концепцию и руководить процессом!
Я серьезно. Много ли вы видели объявлений от программистов, к примеру? Типа, "разработал крутой сервис, нужно натянуть на него дизайн и верстку за долю в проекте"?..
@nepster09 занимает больше места, можно легко запутаться, сложнее работать.
Проще так:
1. в БД попадает исходное значение, за исключением того, что туда попасть не должно (режем теги, например)
2. При выводе в форму ничего не делаем
3. При выводе на сайте экранируем при необходимости.
Пояснение по последнему пункту: иногда возникает ситуация, когда пользователь не имеет права вводить теги, а админ имеет.