M
Size: a a a
2021 February 07
YS
Начнём с того, что ты предлагаешь держать отдельно редактор запроса от интерфейса работы с базой. Это постоянное копирование запроса и переключение между окнами. Продуктивненько так)
Про DDL. Да, окно с ним можно убрать, но GUI построен так, что место под всё хватает. Например, горизонтальный скролл с выводом select * из таблицы с десятками колонок очень помогает. Но в DDL сразу видны индексы, значения по умолчанию и прочее. Разве возможно всё в голове держать? Когда сотни таблиц в десятках баз.
Про переключение результатов я тебя не понял. Делаю два независимых select из двух таблиц и в каждой по 100 результатов. Вот они выведутся не в одном окне, а в разных вкладках. Это удобно, попробуй. Табы откроются сами, на количество результатов.
Я не понимаю, как ты можешь вести обсуждение, если не имеешь опыта
Простой кейс. Есть таблица с текстовой колонкой ~500 символов в каждой строке. Тебе нужно исправить в тексте одной строки одну букву.
Что проще?
1. Делать селект, далее этот текст вставлять в апдейт, экранировать, делать исправление и применять апдейт
2. В результате исправить букву и при blur ячейки автоматом накатится апдейт, при этом если кто-то изменил эту строку, апдейт не пройдёт, о чём gui тебе сообщит
Про DDL. Да, окно с ним можно убрать, но GUI построен так, что место под всё хватает. Например, горизонтальный скролл с выводом select * из таблицы с десятками колонок очень помогает. Но в DDL сразу видны индексы, значения по умолчанию и прочее. Разве возможно всё в голове держать? Когда сотни таблиц в десятках баз.
Про переключение результатов я тебя не понял. Делаю два независимых select из двух таблиц и в каждой по 100 результатов. Вот они выведутся не в одном окне, а в разных вкладках. Это удобно, попробуй. Табы откроются сами, на количество результатов.
Я не понимаю, как ты можешь вести обсуждение, если не имеешь опыта
Простой кейс. Есть таблица с текстовой колонкой ~500 символов в каждой строке. Тебе нужно исправить в тексте одной строки одну букву.
Что проще?
1. Делать селект, далее этот текст вставлять в апдейт, экранировать, делать исправление и применять апдейт
2. В результате исправить букву и при blur ячейки автоматом накатится апдейт, при этом если кто-то изменил эту строку, апдейт не пройдёт, о чём gui тебе сообщит
> Начнём с того, что ты предлагаешь держать отдельно редактор запроса от интерфейса работы с базой.
Я этого не предлагал. И я так обычно не работаю, например.
> Да, окно с ним можно убрать, но GUI построен так, что место под всё хватает.
Это называется "визуальный мусор", кажется?
И нет, не построен же — на том же экране можно разместить больше полезной информации, очевидно.
> Но в DDL сразу видны индексы, значения по умолчанию и прочее. Разве возможно всё в голове держать?
Я не понимаю, зачем мне загромождать экран тем, что сейчас не нужно (захочу — посмотрю)? Ладно, можно убрать — хорошо.
> Делаю два независимых select из двух таблиц и в каждой по 100 результатов.
> Вот они выведутся не в одном окне, а в разных вкладках.
Я понимаю, о чём речь.
> Это удобно, попробуй. Табы откроются сами, на количество результатов.
Иногда удобно, и тогда я так делаю, но чаще всего — нет.
> Я не понимаю, как ты можешь вести обсуждение, если не имеешь опыта
Мне не нужно иметь опыт в пользовании каменного топора, чтобы знать, что это не лучший инструмент.
Или, может, стоит лично сравнить, впустую "сжечь" часть моей жизни, а? ;)
Я "имею" документацию и news этих средств, и рассказы пользующихся — вроде, должно хватать?
Или документация (и т.п.) navicat плоха?
> Тебе нужно исправить в тексте одной строки одну букву.
Мне проще получить update statement, который я посмотрю и потом выполню (или передам на выполнение кому-то) в production.
Если мне подобное будет нужно часто, я "подточу" что-то для этого (сделаю макрос и т.п.).
> и при blur ячейки автоматом накатится апдейт
И это, ещё раз, отвратительно (т.е. UPDATE statement у меня не будет, сделать то, что я написал выше, невозможно), если иной возможности нет.
Я этого не предлагал. И я так обычно не работаю, например.
> Да, окно с ним можно убрать, но GUI построен так, что место под всё хватает.
Это называется "визуальный мусор", кажется?
И нет, не построен же — на том же экране можно разместить больше полезной информации, очевидно.
> Но в DDL сразу видны индексы, значения по умолчанию и прочее. Разве возможно всё в голове держать?
Я не понимаю, зачем мне загромождать экран тем, что сейчас не нужно (захочу — посмотрю)? Ладно, можно убрать — хорошо.
> Делаю два независимых select из двух таблиц и в каждой по 100 результатов.
> Вот они выведутся не в одном окне, а в разных вкладках.
Я понимаю, о чём речь.
> Это удобно, попробуй. Табы откроются сами, на количество результатов.
Иногда удобно, и тогда я так делаю, но чаще всего — нет.
> Я не понимаю, как ты можешь вести обсуждение, если не имеешь опыта
Мне не нужно иметь опыт в пользовании каменного топора, чтобы знать, что это не лучший инструмент.
Или, может, стоит лично сравнить, впустую "сжечь" часть моей жизни, а? ;)
Я "имею" документацию и news этих средств, и рассказы пользующихся — вроде, должно хватать?
Или документация (и т.п.) navicat плоха?
> Тебе нужно исправить в тексте одной строки одну букву.
Мне проще получить update statement, который я посмотрю и потом выполню (или передам на выполнение кому-то) в production.
Если мне подобное будет нужно часто, я "подточу" что-то для этого (сделаю макрос и т.п.).
> и при blur ячейки автоматом накатится апдейт
И это, ещё раз, отвратительно (т.е. UPDATE statement у меня не будет, сделать то, что я написал выше, невозможно), если иной возможности нет.
M
Yaroslav Schekin
> Начнём с того, что ты предлагаешь держать отдельно редактор запроса от интерфейса работы с базой.
Я этого не предлагал. И я так обычно не работаю, например.
> Да, окно с ним можно убрать, но GUI построен так, что место под всё хватает.
Это называется "визуальный мусор", кажется?
И нет, не построен же — на том же экране можно разместить больше полезной информации, очевидно.
> Но в DDL сразу видны индексы, значения по умолчанию и прочее. Разве возможно всё в голове держать?
Я не понимаю, зачем мне загромождать экран тем, что сейчас не нужно (захочу — посмотрю)? Ладно, можно убрать — хорошо.
> Делаю два независимых select из двух таблиц и в каждой по 100 результатов.
> Вот они выведутся не в одном окне, а в разных вкладках.
Я понимаю, о чём речь.
> Это удобно, попробуй. Табы откроются сами, на количество результатов.
Иногда удобно, и тогда я так делаю, но чаще всего — нет.
> Я не понимаю, как ты можешь вести обсуждение, если не имеешь опыта
Мне не нужно иметь опыт в пользовании каменного топора, чтобы знать, что это не лучший инструмент.
Или, может, стоит лично сравнить, впустую "сжечь" часть моей жизни, а? ;)
Я "имею" документацию и news этих средств, и рассказы пользующихся — вроде, должно хватать?
Или документация (и т.п.) navicat плоха?
> Тебе нужно исправить в тексте одной строки одну букву.
Мне проще получить update statement, который я посмотрю и потом выполню (или передам на выполнение кому-то) в production.
Если мне подобное будет нужно часто, я "подточу" что-то для этого (сделаю макрос и т.п.).
> и при blur ячейки автоматом накатится апдейт
И это, ещё раз, отвратительно (т.е. UPDATE statement у меня не будет, сделать то, что я написал выше, невозможно), если иной возможности нет.
Я этого не предлагал. И я так обычно не работаю, например.
> Да, окно с ним можно убрать, но GUI построен так, что место под всё хватает.
Это называется "визуальный мусор", кажется?
И нет, не построен же — на том же экране можно разместить больше полезной информации, очевидно.
> Но в DDL сразу видны индексы, значения по умолчанию и прочее. Разве возможно всё в голове держать?
Я не понимаю, зачем мне загромождать экран тем, что сейчас не нужно (захочу — посмотрю)? Ладно, можно убрать — хорошо.
> Делаю два независимых select из двух таблиц и в каждой по 100 результатов.
> Вот они выведутся не в одном окне, а в разных вкладках.
Я понимаю, о чём речь.
> Это удобно, попробуй. Табы откроются сами, на количество результатов.
Иногда удобно, и тогда я так делаю, но чаще всего — нет.
> Я не понимаю, как ты можешь вести обсуждение, если не имеешь опыта
Мне не нужно иметь опыт в пользовании каменного топора, чтобы знать, что это не лучший инструмент.
Или, может, стоит лично сравнить, впустую "сжечь" часть моей жизни, а? ;)
Я "имею" документацию и news этих средств, и рассказы пользующихся — вроде, должно хватать?
Или документация (и т.п.) navicat плоха?
> Тебе нужно исправить в тексте одной строки одну букву.
Мне проще получить update statement, который я посмотрю и потом выполню (или передам на выполнение кому-то) в production.
Если мне подобное будет нужно часто, я "подточу" что-то для этого (сделаю макрос и т.п.).
> и при blur ячейки автоматом накатится апдейт
И это, ещё раз, отвратительно (т.е. UPDATE statement у меня не будет, сделать то, что я написал выше, невозможно), если иной возможности нет.
Ты в своём ответе про редактор несколько раз сказал. Сейчас ты сказал, что так не делаешь. Раздвоение личности?
Причём тут production? Основная работа с данными в базе происходит во время разработки и если ты во время разработки просишь кого-то сделать апдейт ради одной буквы - стоит ли дальше вести разговор?
Работать с табличными данными в текстовом представлении - это и есть тот самый «каменный топор». Для табличных данных должно быть табличное отображение с ячейками, сортировками, скроллом и удобным выделением.
Про оценку инструмента по рассказам пользующихся - это странно. Ладно, ты можешь для себя сделать выбор, но для того чтобы рекомендовать другим не пользоваться этим инструментом, нужно иметь свой опыт
Причём тут production? Основная работа с данными в базе происходит во время разработки и если ты во время разработки просишь кого-то сделать апдейт ради одной буквы - стоит ли дальше вести разговор?
Работать с табличными данными в текстовом представлении - это и есть тот самый «каменный топор». Для табличных данных должно быть табличное отображение с ячейками, сортировками, скроллом и удобным выделением.
Про оценку инструмента по рассказам пользующихся - это странно. Ладно, ты можешь для себя сделать выбор, но для того чтобы рекомендовать другим не пользоваться этим инструментом, нужно иметь свой опыт
YS
Ты в своём ответе про редактор несколько раз сказал. Сейчас ты сказал, что так не делаешь. Раздвоение личности?
Причём тут production? Основная работа с данными в базе происходит во время разработки и если ты во время разработки просишь кого-то сделать апдейт ради одной буквы - стоит ли дальше вести разговор?
Работать с табличными данными в текстовом представлении - это и есть тот самый «каменный топор». Для табличных данных должно быть табличное отображение с ячейками, сортировками, скроллом и удобным выделением.
Про оценку инструмента по рассказам пользующихся - это странно. Ладно, ты можешь для себя сделать выбор, но для того чтобы рекомендовать другим не пользоваться этим инструментом, нужно иметь свой опыт
Причём тут production? Основная работа с данными в базе происходит во время разработки и если ты во время разработки просишь кого-то сделать апдейт ради одной буквы - стоит ли дальше вести разговор?
Работать с табличными данными в текстовом представлении - это и есть тот самый «каменный топор». Для табличных данных должно быть табличное отображение с ячейками, сортировками, скроллом и удобным выделением.
Про оценку инструмента по рассказам пользующихся - это странно. Ладно, ты можешь для себя сделать выбор, но для того чтобы рекомендовать другим не пользоваться этим инструментом, нужно иметь свой опыт
> Ты в своём ответе про редактор несколько раз сказал. Сейчас ты сказал, что так не делаешь. Раздвоение личности?
SQL shell можно "завернуть" в любой адекватный редактор (даже современные "блокноты" это умеют).
> Основная работа с данными в базе происходит во время разработки
И мне почему-то обычно не нужно править их описанным Вами образом. Если будет нужно — см. выше.
> стоит ли дальше вести разговор?
Да это дело Ваше.
> Работать с табличными данными в текстовом представлении - это и есть тот самый «каменный топор».
Правда? Кто это сказал или доказал? ;)
> для того чтобы рекомендовать другим не пользоваться этим инструментом, нужно иметь свой опыт
Нет, не нужно. См. про каменный топор (и сотни подобных инструментов).
SQL shell можно "завернуть" в любой адекватный редактор (даже современные "блокноты" это умеют).
> Основная работа с данными в базе происходит во время разработки
И мне почему-то обычно не нужно править их описанным Вами образом. Если будет нужно — см. выше.
> стоит ли дальше вести разговор?
Да это дело Ваше.
> Работать с табличными данными в текстовом представлении - это и есть тот самый «каменный топор».
Правда? Кто это сказал или доказал? ;)
> для того чтобы рекомендовать другим не пользоваться этим инструментом, нужно иметь свой опыт
Нет, не нужно. См. про каменный топор (и сотни подобных инструментов).
2021 February 10
v
Всем привет)
есть таблица:
id(AI) / user_id(UNIQUE) / point(INT)
1 / 1 / 50
2 / 15 / 1
3 / 11 / 105
4 / 3 / 44
.. / .. / ..
Как мне составить запрос чтобы узнать допустим у user_id 11 на каком он месте в зависимости от point, у user_id самый большой point я должен получить что он на первом месте. Заранее спасибо
есть таблица:
id(AI) / user_id(UNIQUE) / point(INT)
1 / 1 / 50
2 / 15 / 1
3 / 11 / 105
4 / 3 / 44
.. / .. / ..
Как мне составить запрос чтобы узнать допустим у user_id 11 на каком он месте в зависимости от point, у user_id самый большой point я должен получить что он на первом месте. Заранее спасибо
EK
прямо все лучшие практики в одном скрине
EK
Критике рад, но конструктивной
sql injection (почитай о placeholders)
md5 для паролей не рекомендованно почитай о password_hash
загрузка файлов и имя пользовательского файла, можно перезаписать им что угодно (куда может писать вебсервер)
достаточно конструктивно?
md5 для паролей не рекомендованно почитай о password_hash
загрузка файлов и имя пользовательского файла, можно перезаписать им что угодно (куда может писать вебсервер)
достаточно конструктивно?
SD
sql injection (почитай о placeholders)
md5 для паролей не рекомендованно почитай о password_hash
загрузка файлов и имя пользовательского файла, можно перезаписать им что угодно (куда может писать вебсервер)
достаточно конструктивно?
md5 для паролей не рекомендованно почитай о password_hash
загрузка файлов и имя пользовательского файла, можно перезаписать им что угодно (куда может писать вебсервер)
достаточно конструктивно?
Понял, спасибо, я в самом начале изучения прям действительно в начале, поэтому ещё не со всем разобрался ,да, конструктивно
EK
по поставленному вопросу почему не работает, там используется переменная $connect которая тут не объявлена, возможно она объявляется в connect.php, но это тут не видно
в любом случае так тоже лучше не делать
другая причина возможная пути для сохранения относительные, лучше задавать абсолютные используй DIR
ну и третий совет это задавать такие вопросы в чаты про php
в любом случае так тоже лучше не делать
другая причина возможная пути для сохранения относительные, лучше задавать абсолютные используй DIR
ну и третий совет это задавать такие вопросы в чаты про php
SD
по поставленному вопросу почему не работает, там используется переменная $connect которая тут не объявлена, возможно она объявляется в connect.php, но это тут не видно
в любом случае так тоже лучше не делать
другая причина возможная пути для сохранения относительные, лучше задавать абсолютные используй DIR
ну и третий совет это задавать такие вопросы в чаты про php
в любом случае так тоже лучше не делать
другая причина возможная пути для сохранения относительные, лучше задавать абсолютные используй DIR
ну и третий совет это задавать такие вопросы в чаты про php
Понял, спасибо большое! Хорошего вечера!