thảo luận Các thắc mắc cơ bản - Newbie đặt các câu hỏi cơ bản thì vào đây, không lập thread ngoài!!!

Status
Not open for further replies.
Chào các thím, hiện em đang là một thằng sinh viên năm 2 của một trường ĐH CNTT tại TP.Đà Nẵng. Nhưng bây giờ em nhận thấy là mình không hợp với việc ngồi gõ code, một phần vì em cũng không thích. Tâm sự với thằng bạn thì nó bảo m theo làm tester cũng đc, em cũng đã suy nghĩ và tìm hiểu sơ qua nhưng vẫn còn một vài thắc mắc mong các bác có thể giúp em với ạ.

Đầu tiên là em nhận thấy ngành này đa phần là các bạn nữ , mà tính em thì vốn lại nhát gái với cả lạc vào một môi trường toàn là nữ giới thì em cảm thấy lạc lõng lắm ạ. Thứ hai, em muốn biết là việc lương thưởng hay thăng tiến trong nghề này ra sao, bởi vì khi xem các mô tả công việc thì em cảm thấy nó khá phụ hợp với em nên nếu đc em muốn theo ngành này lâu dài, đặc biệc là về các job testing game.

Đó là những thắc mắc của em, hy vọng sẽ đc mọi người giải đáp. Nếu đc thì những người đã và đang là một tester giải đáp cho em thì càng tốt nữa ạ.
sao bạn nghĩ bạn k thích hợp ngồi code nhỉ? bạn đang học mấy ngôn ngữ kiểu C hoặc C++ đúng k?
 
Các bác cho em hỏi về cách xử lý case này với ạ.
Database của công ty em trước được thiết kế không tốt lắm, có 1 quan hệ 1 - nhiều đang được lưu như thế này : "id1, id2,id3,id4,id5"
Bây giờ muốn tách ra thành một bảng riêng và đang có 2 lựa chọn
1. Tạo bảng mới cho quan hệ 1-n đấy. Dữ liệu mới sẽ được lưu vào bảng mới đó, còn dữ liệu cũ vấn sẽ đọc từ bảng cũ kia. Cách này thì code sẽ phải quản lý cả 2 bảng, có 1 chút phức tạp.
2. Viết script (đọc data từ bảng cũ, sau đó insert vào bảng mới) để migrate toàn bộ data cũ sang bảng mới.

-- UPDATE --
dữ liệu của bảng mới rơi vào khoảng 2 triệu record.
downtime cho phép là 10p ạ

Các bác cho em xin ý kiến với ạ.
 
Last edited:
Background điện tử, cũng tập tò C/C++ rồi mấy fen à, nay cần nâng cao, đâm luôn embedded vượt qua mùa cách ly này
n56YfiH.png
, tiếng Việt càng tốt, đỡ tốn thời gian, tks mấy fences.
 
sao bạn nghĩ bạn k thích hợp ngồi code nhỉ? bạn đang học mấy ngôn ngữ kiểu C hoặc C++ đúng k?
một phần vì em cũng ko thích nữa chứ ko phải ko hợp ạ, do ban đầu ko bik phải học gì nên em mới đăng kí CNTT vì nó hot.
 
Các bác cho em hỏi về cách xử lý case này với ạ.
Database của công ty em trước được thiết kế không tốt lắm, có 1 quan hệ 1 - nhiều đang được lưu như thế này : "id1, id2,id3,id4,id5"
Bây giờ muốn tách ra thành một bảng riêng và đang có 2 lựa chọn
1. Tạo bảng mới cho quan hệ 1-n đấy. Dữ liệu mới sẽ được lưu vào bảng mới đó, còn dữ liệu cũ vấn sẽ đọc từ bảng cũ kia. Cách này thì code sẽ phải quản lý cả 2 bảng, có 1 chút phức tạp.
2. Viết script (đọc data từ bảng cũ, sau đó insert vào bảng mới) để migrate toàn bộ data cũ sang bảng mới.

Các bác cho em xin ý kiến với ạ.
Cần thêm các thông tin khác như: downtime cho phép, lượng dữ liệu, các khảo sát sơ bộ khác ....

Nếu chỉ là 1 db OLTP nhỏ nhỏ thì phương án 2 nhé, không nên chơi multiversion vì sẽ có nhiều hệ lụy về sau trên cả code lẫn database.
 
Cần thêm các thông tin khác như: downtime cho phép, lượng dữ liệu, các khảo sát sơ bộ khác ....

Nếu chỉ là 1 db OLTP nhỏ nhỏ thì phương án 2 nhé, không nên chơi multiversion vì sẽ có nhiều hệ lụy về sau trên cả code lẫn database.
em update r ạ
Code:
dữ liệu của bảng mới rơi vào khoảng 2 triệu record.
downtime cho phép là 10p
 
em update r ạ
Code:
dữ liệu của bảng mới rơi vào khoảng 2 triệu record.
downtime cho phép là 10p
Bạn nhớ nha, data size đừng bao giờ chỉ tính bằng số row nha.

Ok, với 10p downtime thì bài toán này lại thành thú vị rồi đây. Để tối mình update post này suggest vài case xem sao.

via theNEXTvoz for iPhone
 
Bạn nhớ nha, data size đừng bao giờ chỉ tính bằng số row nha.

Ok, với 10p downtime thì bài toán này lại thành thú vị rồi đây. Để tối mình update post này suggest vài case xem sao.

via theNEXTvoz for iPhone
ngoài số row ra thì cần phải quan tâm đến những thông số nào v bác
 
Các bác cho em hỏi về cách xử lý case này với ạ.
Database của công ty em trước được thiết kế không tốt lắm, có 1 quan hệ 1 - nhiều đang được lưu như thế này : "id1, id2,id3,id4,id5"
Bây giờ muốn tách ra thành một bảng riêng và đang có 2 lựa chọn
1. Tạo bảng mới cho quan hệ 1-n đấy. Dữ liệu mới sẽ được lưu vào bảng mới đó, còn dữ liệu cũ vấn sẽ đọc từ bảng cũ kia. Cách này thì code sẽ phải quản lý cả 2 bảng, có 1 chút phức tạp.
2. Viết script (đọc data từ bảng cũ, sau đó insert vào bảng mới) để migrate toàn bộ data cũ sang bảng mới.

-- UPDATE --
dữ liệu của bảng mới rơi vào khoảng 2 triệu record.
downtime cho phép là 10p ạ

Các bác cho em xin ý kiến với ạ.
Quan hệ 1-n bên bạn bị ngược à. Bảng con phải lưu FK là PK của bảng cha chứ. Trong trường hợp này viết 1 cái console app để migrate là đơn giản nhất, vì còn phải tách chuỗi nữa mà. 2 triệu row là con số nhỏ thôi, 10p thừa sức.

ngoài số row ra thì cần phải quan tâm đến những thông số nào v bác
Số row thôi, có index của PK rồi mà
 
E là sv năm 2 ở 1 trường ĐH ở TPHCM,em đang học kiến thức nền và chuẩn bị vô chuyên ngành. Theo các bác e nên try hard ngôn ngữ nào để thành thạo rồi ra trường làm các bác. Hiện tại e nắm được của C++,C# và kiến thức nền về lập trình rồi :too_sad:

via theNEXTvoz for iPhone
 
E là sv năm 2 ở 1 trường ĐH ở TPHCM,em đang học kiến thức nền và chuẩn bị vô chuyên ngành. Theo các bác e nên try hard ngôn ngữ nào để thành thạo rồi ra trường làm các bác. Hiện tại e nắm được của C++,C# và kiến thức nền về lập trình rồi :too_sad:

via theNEXTvoz for iPhone
:V câu này khó nói lắm bác, bác định theo gì mới chắc cú đc
 
Quan hệ 1-n bên bạn bị ngược à. Bảng con phải lưu FK là PK của bảng cha chứ. Trong trường hợp này viết 1 cái console app để migrate là đơn giản nhất, vì còn phải tách chuỗi nữa mà. 2 triệu row là con số nhỏ thôi, 10p thừa sức.


Số row thôi, có index của PK rồi mà
Đọc cái đoạn 10p thừa sức của bác lại khiến em buồn cười quá :byebye::byebye:

Sorry bạn rùa, nay bận quá không update được gì.
Dowtime 10p của bạn vui phết đó. Mình cũng từng qua mấy case như này và thường mất khoảng 30p/1h nếu không chơi mấy bài blue green :stick:

Edit: các case dưới 30p bọn em hay gọi là "full auto". Vì đơn giản bác muốn stop + start 1 con services cũng mất 5p rồi.
Mấy case như này sẽ cần có script auto và tập với nhau khoảng 3-5 lần trước khi phang.
Chưa kể dự phòng chuyện rollback, mất tầm 5-10p nữa.
Vì vậy các case migrate dưới 30p bọn em sợ vc.
  • Tốn tài nguyên và owner thường không đồng ý: vì thấy nó dễ vc mà.
  • Chơi mạo hiểm: ok trace đống transaction chắc mất gần tuần, mà khổ này ai thấu.
  • Xin off 1h: ok, cứ lúc phang thì nó lỗi, mysql binlog, pg wal, sql server fg. Rất chi là vui
via theNEXTvoz for iPhone
 
Last edited:
Đọc cái đoạn 10p thừa sức của bác lại khiến em buồn cười quá :byebye::byebye:

Sorry bạn rùa, nay bận quá không update được gì.
Dowtime 10p của bạn vui phết đó. Mình cũng từng qua mấy case như này và thường mất khoảng 30p/1h nếu không chơi mấy bài blue green :stick:

Edit: các case dưới 30p bọn em hay gọi là "full auto". Vì đơn giản bác muốn stop + start 1 con services cũng mất 5p rồi.
Mấy case như này sẽ cần có script auto và tập với nhau khoảng 3-5 lần trước khi phang.
Chưa kể dự phòng chuyện rollback, mất tầm 5-10p nữa.
Vì vậy các case migrate dưới 30p bọn em sợ vc.
  • Tốn tài nguyên và owner thường không đồng ý: vì thấy nó dễ vc mà.
  • Chơi mạo hiểm: ok trace đống transaction chắc mất gần tuần, mà khổ này ai thấu.
  • Xin off 1h: ok, cứ lúc phang thì nó lỗi, mysql binlog, pg wal, sql server fg. Rất chi là vui
via theNEXTvoz for iPhone
oki ạ, e cảm ơn bác
 
Đọc cái đoạn 10p thừa sức của bác lại khiến em buồn cười quá :byebye::byebye:

via theNEXTvoz for iPhone
Trường hợp này chỉ là

SQL:
update child_table
set    parent_id = @parent_id
where  child_id = any (@child_ids)

Nếu vậy thì cũng nhanh mà nhỉ, hay tôi hiểu sai gì à? Nếu sử dụng Postgres hỗ trợ array thì có thể viết sql script luôn, lúc ấy càng nhanh hơn.
 
Đọc cái đoạn 10p thừa sức của bác lại khiến em buồn cười quá :byebye::byebye:

Sorry bạn rùa, nay bận quá không update được gì.
Dowtime 10p của bạn vui phết đó. Mình cũng từng qua mấy case như này và thường mất khoảng 30p/1h nếu không chơi mấy bài blue green :stick:

Edit: các case dưới 30p bọn em hay gọi là "full auto". Vì đơn giản bác muốn stop + start 1 con services cũng mất 5p rồi.
Mấy case như này sẽ cần có script auto và tập với nhau khoảng 3-5 lần trước khi phang.
Chưa kể dự phòng chuyện rollback, mất tầm 5-10p nữa.
Vì vậy các case migrate dưới 30p bọn em sợ vc.
  • Tốn tài nguyên và owner thường không đồng ý: vì thấy nó dễ vc mà.
  • Chơi mạo hiểm: ok trace đống transaction chắc mất gần tuần, mà khổ này ai thấu.
  • Xin off 1h: ok, cứ lúc phang thì nó lỗi, mysql binlog, pg wal, sql server fg. Rất chi là vui
via theNEXTvoz for iPhone


cái câu hỏi của bạn kia có cái này tôi ko hiểu lắm:
Database của công ty em trước được thiết kế không tốt lắm, có 1 quan hệ 1 - nhiều đang được lưu như thế này : "id1, id2,id3,id4,id5"

--> có nghĩa là gì nhỉ??? quan hệ 1 -n trên 2 table đúng ko? hay là ý bạn ấy nói là chỉ có 1 table thôi, quan hệ ở đây là id1 -> id2,id3,id4,id5
Tôi hiểu vậy đúng ko nhỉ?
 
Status
Not open for further replies.
Back
Top