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

да. Но про механизм связи "многие ко многим" через отдельную таблицу мне рассказали коллеги именно на подобный дурацкий вопрос.

да. Но про механизм связи "многие ко многим" через отдельную таблицу мне рассказали коллеги именно на подобный дурацкий вопрос.

то есть раньше ты не догадывался что данные хранят в таблицах и их там можно сортировать по всякому и выбирать как нужно?

то есть раньше ты не догадывался что данные хранят в таблицах и их там можно сортировать по всякому и выбирать как нужно?

догадывался и таки умел, конечно :) Там вопрос был в том, что есть сущности А (много) и их свойства Б (десяток), и каждая сущность А может обладать некоторыми свойствами Б. Но их количество тоже может сильно варьироваться, могут добавляться новые и так далее чтожеделать. Ответ был, разумеется, завести таблицу с указателями на А и на Б. В универе я то же самое услышал гораздо позже (и гораздо менее понятным языком рассказанное). Сорри за кривой рассказ, 10 лет уже прошло, детали в памяти изрядно стерлись.

Здравствуйте как лучше хранить характеристики спецтехники, когда их может быть от 1 до 20, и чтобы их можно было фильтровать?

если у тебя список характеристик постоянен и меняться не будет - заводи их как столбцы в таблицу с DEFAULT NULL, оно для этого и создано.

если у тебя список характеристик постоянен и меняться не будет - заводи их как столбцы в таблицу с DEFAULT NULL, оно для этого и создано.

Спасибо

Доброго времени суток. Такой вопрос. Нужно сравнить есть ли такой персон в бд. Если имеется то обновить, если не имеется то добавить. Допустим будет млн записей в бд. Как это осуществить?

Путем поиска и сравнения новой персоны с существующими

догадывался и таки умел, конечно :) Там вопрос был в том, что есть сущности А (много) и их свойства Б (десяток), и каждая сущность А может обладать некоторыми свойствами Б. Но их количество тоже может сильно варьироваться, могут добавляться новые и так далее чтожеделать. Ответ был, разумеется, завести таблицу с указателями на А и на Б. В универе я то же самое услышал гораздо позже (и гораздо менее понятным языком рассказанное). Сорри за кривой рассказ, 10 лет уже прошло, детали в памяти изрядно стерлись.

доо и ты можешь придумать еще кучу всякого и странного. а можешь просто сделать таблицу в 100500 столбиков и писать каждый девайс в строчку

Хорошо. Почитаю replace. Спасибо.

Replace тут вовсе не обязателен

потому что больше оно и нафиг не нужно

Здравствуйте как лучше хранить характеристики спецтехники, когда их может быть от 1 до 20, и чтобы их можно было фильтровать?

Е, что за тупые вопросы то пошли...

Е, что за тупые вопросы то пошли...

это нормально, любая группа профессионалов по владению микроскопом рано или поздно сталкивается с вопросами "а как забить им гвоздь?" ;)

наблюдалось везде, кроме линукстолкс, который был таким изначально

это нормально, любая группа профессионалов по владению микроскопом рано или поздно сталкивается с вопросами "а как забить им гвоздь?" ;)

это должно ка кто оправдывать вопрошающего?

это должно ка кто оправдывать вопрошающего?

он поступает неправильно, но его можно понять. Он внезапно узнал про абсолютно новую для него тему, базы данных. И надо сделать что-то простое, вроде INSERT or UPDATE из треда выше. И он лезет даже гуглить (потому что он умеет это делать), а там какие-то мегатонны информации, форейн киз, уникальные индексы, шарды и бинарная совместимость Перконы с Марией. И тогда он приходит сюда, а тут сидят Благородные Доны, все с виду такие дофига прошаренные, и ведут разговор про оптимизацию удаления через constraint. И он делает вывод, что эти-то уж точно могут справиться с его примитивной задачей. И спрашивает. А в ответ получает в лучшем случае погугли, а в худшем его плоско троллят и, когда он обижается, банят КЕМ.

он поступает неправильно, но его можно понять. Он внезапно узнал про абсолютно новую для него тему, базы данных. И надо сделать что-то простое, вроде INSERT or UPDATE из треда выше. И он лезет даже гуглить (потому что он умеет это делать), а там какие-то мегатонны информации, форейн киз, уникальные индексы, шарды и бинарная совместимость Перконы с Марией. И тогда он приходит сюда, а тут сидят Благородные Доны, все с виду такие дофига прошаренные, и ведут разговор про оптимизацию удаления через constraint. И он делает вывод, что эти-то уж точно могут справиться с его примитивной задачей. И спрашивает. А в ответ получает в лучшем случае погугли, а в худшем его плоско троллят и, когда он обижается, банят КЕМ.

ээээ что именно он узнает про базы данных? что они существуют? и на этом все? то есть он чего то там програмировал и никогда не кассался баз данных? или не умел делать табличку в экселе? или не видел никогда картотеку книг в библиотеке? не видел оглавление в книжках?

базы данных это просто автоматизация старого древнего процесса. который делали всегда ручками

нихрена нового и иновационного

все тоже самое только чуть быстрее

вот можно 20 баксов поставить на то что весь его парк техники умещается в 1000 строк

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

http://enterprise.indiegogo.com/arrow

во лучше зацените какую штуку нарыл

бабки раздают за просто так. на развитие всяких проектов

он поступает неправильно, но его можно понять. Он внезапно узнал про абсолютно новую для него тему, базы данных. И надо сделать что-то простое, вроде INSERT or UPDATE из треда выше. И он лезет даже гуглить (потому что он умеет это делать), а там какие-то мегатонны информации, форейн киз, уникальные индексы, шарды и бинарная совместимость Перконы с Марией. И тогда он приходит сюда, а тут сидят Благородные Доны, все с виду такие дофига прошаренные, и ведут разговор про оптимизацию удаления через constraint. И он делает вывод, что эти-то уж точно могут справиться с его примитивной задачей. И спрашивает. А в ответ получает в лучшем случае погугли, а в худшем его плоско троллят и, когда он обижается, банят КЕМ.

Да, такова жизнь. И ?

Здравствуйте как лучше хранить характеристики спецтехники, когда их может быть от 1 до 20, и чтобы их можно было фильтровать?

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

Я просто думал что это неправильно будет

На основе чего к тебе пришла такая мысль?

да. Но про механизм связи "многие ко многим" через отдельную таблицу мне рассказали коллеги именно на подобный дурацкий вопрос.

Т.е книги ты не читал? Странно, с виду не скажешь...

На основе чего к тебе пришла такая мысль?

2 друга ботана из универа так сказали

догадывался и таки умел, конечно :) Там вопрос был в том, что есть сущности А (много) и их свойства Б (десяток), и каждая сущность А может обладать некоторыми свойствами Б. Но их количество тоже может сильно варьироваться, могут добавляться новые и так далее чтожеделать. Ответ был, разумеется, завести таблицу с указателями на А и на Б. В универе я то же самое услышал гораздо позже (и гораздо менее понятным языком рассказанное). Сорри за кривой рассказ, 10 лет уже прошло, детали в памяти изрядно стерлись.

Здравствуйте как лучше хранить характеристики спецтехники, когда их может быть от 1 до 20, и чтобы их можно было фильтровать? Где ты тут видишь МОЖЕТ ОБЛАДАТЬ НЕКОТОРЫМИ и ДОБАВЛЯТЬСЯ НОВЫЕ?

Т.е книги ты не читал? Странно, с виду не скажешь...

еще раз: это было очень давно. Это просто скорее как иллюстрация того, что иногда пионер даже не знает, как правильно сформулировать вопрос, чтобы нагуглить ответ.

2 друга ботана из универа так сказали

Ну , процитируй их.

Здравствуйте как лучше хранить характеристики спецтехники, когда их может быть от 1 до 20, и чтобы их можно было фильтровать? Где ты тут видишь МОЖЕТ ОБЛАДАТЬ НЕКОТОРЫМИ и ДОБАВЛЯТЬСЯ НОВЫЕ?

ок, если уж мы будем цепляться к словам: где ты тут видишь ОБЯЗАТЕЛЬНО ОБЛАДАЕТ ВСЕМИ и СПИСОК ХАРАКТЕРИСТИК НЕИЗМЕНЯЕМ?

Они сказали что характеристики нужно хранить отдельно, в таблице характеристики. В коттрой будет 3 столбца id id_texniki и само значение

Здравствуйте как лучше хранить характеристики спецтехники, когда их может быть от 1 до 20, и чтобы их можно было фильтровать? Где ты тут видишь МОЖЕТ ОБЛАДАТЬ НЕКОТОРЫМИ и ДОБАВЛЯТЬСЯ НОВЫЕ?

и если уж мы разрабатываем решение по работе с неким списком - лучше бы, чтобы оно поддерживало отсутствующие/неприменимые значения (вроде емкости бензобака в телеге) и изменение списка характеристик.

Но я потом понял что фильтровать то их невозможно

Но я потом понял что фильтровать то их невозможно

ты неправильно понял

познай силу INNER JOIN

Они сказали что характеристики нужно хранить отдельно, в таблице характеристики. В коттрой будет 3 столбца id id_texniki и само значение

Не видя технического задания на разработку системы я не могу дать такие рекомендации. Так можно делать, но БД будет работать сложнее. И тебе будет сложнее писать запросы. ОЧЕНЬ СИЛЬНО сложнее. Это всё для того, чтобы находу можно было бы добавить одно свойство или удалить другое.

хотя нет, скорее не INNER, а LEFT - поскольку характеристика может отсутствовать.

Но я потом понял что фильтровать то их невозможно

Фильтровать базар всегда возможно.

Не видя технического задания на разработку системы я не могу дать такие рекомендации. Так можно делать, но БД будет работать сложнее. И тебе будет сложнее писать запросы. ОЧЕНЬ СИЛЬНО сложнее. Это всё для того, чтобы находу можно было бы добавить одно свойство или удалить другое.

+++

ок, если уж мы будем цепляться к словам: где ты тут видишь ОБЯЗАТЕЛЬНО ОБЛАДАЕТ ВСЕМИ и СПИСОК ХАРАКТЕРИСТИК НЕИЗМЕНЯЕМ?

Именно поэтому я и написал: почему пошли такие тупые вопросы.

Но я потом понял что фильтровать то их невозможно

кого их?

Характеристики

Если всего 3 столбца, хранить да можна, но фильтровать точно нет

Так. Я пойду поработаю, пожалуй. Куда-то мы не туда заехали...

Если всего 3 столбца, хранить да можна, но фильтровать точно нет

смотри. У тебя есть таблица детей (id, name) 1, Петя 2, Вася 3, Маша и городов, где они живут (id, city) (id - айди ребенка) 1, Питер 2, Москва 3, Москва Ты вполне можешь вытащить всех москвичей SELECT name, city FROM children INNER JOIN cities on cities.id = children.id WHERE city="Москва"; P.S. Да, это еще не предел нормализации и я тоже вижу, как можно это допилить. И знаю, когда это нужно делать, а когда не нужно. В этом примере это не нужно.

Если всего 3 столбца, хранить да можна, но фильтровать точно нет

Это почему это?

@zgorinich иди читай про Джойны...

по полям length_boom и boom_extension_length это разве возможно

по полям length_boom и boom_extension_length это разве возможно

Где ты там поля видишь?

ну строки

Я вижу только матрас с цифирьками и буковками.

и я про это, что это невозможно фильровать

Они сказали что характеристики нужно хранить отдельно, в таблице характеристики. В коттрой будет 3 столбца id id_texniki и само значение

ЗАЧЕМ хранить характеристики отдельно? вполне возможно что это даже не будут не разные столбцы а всего один или два

смотри. У тебя есть таблица детей (id, name) 1, Петя 2, Вася 3, Маша и городов, где они живут (id, city) (id - айди ребенка) 1, Питер 2, Москва 3, Москва Ты вполне можешь вытащить всех москвичей SELECT name, city FROM children INNER JOIN cities on cities.id = children.id WHERE city="Москва"; P.S. Да, это еще не предел нормализации и я тоже вижу, как можно это допилить. И знаю, когда это нужно делать, а когда не нужно. В этом примере это не нужно.

ты нифига не знаешь сколько и какие у него характеристики. выносить в отдельную таблицу количество колес у машин, ну это весело конечно, но нахрена. особенно если машин всего десяток

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

и я про это, что это невозможно фильровать

это фильтруется легко и тривиально. Ты прочел, как работают джойны?

да я джоинил таблицу

но сильно не углублялся

А вот углубись. И посмотри, как можно результат джойна фильтровать по полю

но сильно не углублялся

как бы нельзя несильно или сильно углубляться в знание SQL, его просто надо знать весь, чтобы работать с БД

Сейчас можно сложные структуры, особенно пришедшие из вне, или хранящиеся в xml, json можно прямо целиком в полях хранить и обрабатывать...

Сейчас можно сложные структуры, особенно пришедшие из вне, или хранящиеся в xml, json можно прямо целиком в полях хранить и обрабатывать...

да ты шо? не может быть. тебя не прибьют? ну за то что ты открыл нам страшную тайну

подозреваю что хороший архитектор тебя придушит за такие идеи хранения и обработки

а админ еще будет долго пинать твой труп ногами

Да вперед.. Навидался разных... Сколько людей, столько мнений... ?

то что это как то работает, совсем не значит что это нужно использовать. :)

мнение тут всего одно. и оно относительно производительности данных конструкций.

да оно работает. но устанешь его железом заваливать.

О терерь оказывается это Даже заработать может! Хохо!

и давай я выступлю в роли экстрасенса " ТЫ ЗНАЕШЬ СКОЛЬКО СТОИТ ВРЕМЯ РАЗРАБОТЧИКА. А ЖЕЛЕЗО ДЕШЕВЛЕ".

так себе довод. труд обезьян с клавиатурой нынче чуть дороже чем кричать СВОБОДНАЯ КАССА в макдональдсе.

Не.. Банальнее... Есть работающие, а асм все равно быстрее

асм не достаточно универсальный

и это его минус

самый большой

и просто банально перебильдить асм не получится

как только сдохнет последний проц для которого была софтина на асме, то и садись кодить с начала

Начнутся тормоза, просто вынесешь наружу... Или дохерилион других возможностей, зато на конвертации мб даже выиграешь... Да что я. Каждая табличка ж вест терабайты и обрабатывается непрерывно... ?

и хранение данных это не об асм и япах

О любитель тотального контроля!

любитель тотальных оптимизаций

но ты продолжай в том же духе. чем больше таких как ты. тем более востребованы такие как я :)

Надо ж свою компИтенцию АпрОвдать...

жги еще

Да пжалуста... Кстати, нам нужны опытные... Можь переедешь ?, найдете общий язык...

куда переезжать?

Кстати, да, а то что щас данные нужно чаще просто извлекать, преобразовывать и передавать, чем обрабатывать в бд - это ж так...

пошел чумадан паковать

если данные нормализованы то их не придется обрабатывать в бд. достаточно простых селектов и инзертов

но большинство не умеет в нормализацию. от слова совсем

Ко, а потом сто слоев и промежуточных структур... Ну это уже чужие проблемы...

а если валить в sql джейсонами. то удачи тебе с такой затеей. облака ждут тебя. они рады зарабатывать на подобных проектах

нет там никакх слоев и промежуточных структур. просто ты не умеешь в данные и по всей видимости не видел хорошо построеных структур

так че? куда переезжаем то?

Да я как то даже стесняюсь написать... Просвой скромный городок...

Да еще в России...